Introduction

I recently acquired a Mikrotik CCR2004-1G-12S+2XS, which is a much faster, much more modern router than the CCR1036-8G-2S+ routers I was using previously. This gives me enough router CPU power to run BGP with full routes, and RPKI validate the routing table.

I looked at the software options available to me, and I picked routinator as my first RTR software to test.

Router Config

It is required to establish connections to your RTR servers.

/routing rpki
add address=192.0.2.130 disabled=no expire-interval=7200 \
  group=HextetRPKI port=3323 preference=10 refresh-interval=3600 \
  retry-interval=600 vrf=main
add address=192.0.2.131 disabled=no expire-interval=7200 \
  group=HextetRPKI port=3323 preference=10 refresh-interval=3600 \
  retry-interval=600 vrf=main

Additionally, it is required to take some action based on the validity. This is done in routing filters. The actions taken in this example are to reject invalid routes. Valid routes are treated to special treatment by having their BGP local-preference value incremented by 1. A large community could be added for valid routes if desired.

/routing filter rule
add chain=RPKI_Validate disabled=no rule="rpki-verify HextetRPKI"
add chain=RPKI_Validate disabled=no rule="if (rpki invalid) {\r\
    \n  reject;\r\
    \n}"
add chain=RPKI_Validate disabled=no rule="if (rpki valid) {\r\
    \n  set bgp-local-pref +1;\r\
    \n}"
add chain=RPKI_Validate disabled=no rule="return;"

In my case I jump to the RPKI_Validate section from Transit and Peering filtering, after doing basic route cleaning.

/routing filter rule
add chain=transit_in_v4 disabled=no rule="jump Protect_Transit_In;"
add chain=transit_in_v4 disabled=no rule="jump RPKI_Validate;"
add chain=transit_in_v4 disabled=no rule="if (dst in 0.0.0.0/0 && dst-len in 8-24) {\r\
    \n  accept;\r\
    \n} else {\r\
    \n  reject;\r\
    \n}"

Observations

• A router only connects to one RTR server at a time, higher preference values will get connected to first

When I added a 2nd RTR server the router didn’t automatically connect to it in addition to the first one it was already connected to. However when I caused the connection to fail with the first RTR server, the 2nd did get used. Likewise, there was no failback when the first became available.

• RPKI invalid doesn’t automatically mean reject, local policy decisions are required

The action taken when a route is invalid, or valid is undefined. You could depreference RPKI invalid routes or drop them entirely. Similarly you could take a wide variety of actions on RPKI valid routes (or RPKI unknown routes).

• The number of ROAs can vary wildly from one minute to the next

Ok maybe not one minute to the next, but even going forward 15 minutes there might be 5 new ROAs. There are often 100 or more being created in a day. Since routinator has a json status API I could easily track and graph this data, however rpki.cloudflare.com already tracks this data in chart form where it is very obvious the number of ROAs is growing.

• Really pretty easy??

It seems like the entire process is fairly easy, routinator doesn’t need you to jump through hoops to get the ARIN TAL anymore and just starts working downloading, maintaining, and refreshing its data. RTR connnections are easy to configure in RouterOS v7 and the hardest part is figuring out how to apply the validation in filter form and what your local policies are going to be.