User Tools

Site Tools



Part-3 : Configuring Routers to filter against ROAs

Address Plan

Router Access IP eth2 (to Internal Validator) eth3 (to eBGP / External Validator)
RX 10.10.1.X 10.20.X.1 10.30.1.X

where X is your group number

ROA table

Router Router Router AS# ROA/route
R1 R9 R17 135533
R2 R10 R18 135534
R3 R11 R19 135535
R4 R12 R20 135536
R5 R13 135537
R6 R14 135538
R7 R15 135539
R8 R16 135540

Lab Notes

  • For this lab, the RPKI Validator (Routinator) has been installed and configured by the instructor as shown in the topology. The validator's IP address is
  • To simplify the configuration, the routers will establish eBGP session in pairs as shown below:
R1 <--> R2
R3 <--> R4
R5 <--> R6
R7 <--> R9
R17 <--> R18
R19 <--> R20
  • Each router also has a connection to the RPKI validator to allow RTR (rpki-to-router) sessions.
  • ROAs have already been created for each of the prefixes with corresponding origin AS numbers ( AS135533 - AS135540 ) as shown in the table above.

Lab Exercise

1. Login to your group's router, where X is your group number:

ssh bknix@10.10.1.X

2. We use FRR IP Routing Suite as the router which can be running on linux. It contains dedicated shell called 'VTYSH' which maintains CLI interface for each daemons. Most commands are pretty much like CISCO IOS.

sudo vtysh
  • to enter configure mode, type config terminal or conf t
     R1# config terminal
  • to save configuration, type write or wr
     R1# write

3. Verify connectivity to your Internal and External Validator

ping 10.20.X.2

4. Configure eBGP with your neighbor (make sure its the correct neighbor). Example below for R1's eBGP session with R2:

router bgp 135533
   neighbor remote-as 135534
   address-family ipv4 unicast
      neighbor activate

5. Make sure the eBGP session is up with your neighbor

sh bgp ipv4 unicast summary
  • Note: You will not see any prefixes received from your neighbor yet.

6. Announce the correct prefix (based on the address plan table above) to your neighbor. Example below is for R3:

ip route null0
router bgp 135535
   address-family ipv4 unicast
   network mask

7. Check/Verify routes learned from your neighbor. Example, for R1 to verify received routes from its neighbor R2:

sh bgp ipv4 unicast neighbors routes

8. Verify the BGP table:

sh bgp ipv4 unicast

9. Verify the routing table for BGP learned routes

sh ip route bgp

10. Setup RTR (rpki-to-router) session with the Internal RPKI validator. Example for R7:

rpki cache 3323 preference 1

NOTE: Since the router will now pull the validated ROA cache using the RTR protocol from the Validator, it might take a while.

11. Verify the RTR session with the Validator

show rpki cache-server
show rpki cache-connection
  • The output should look like something below:

12. Look at all the valid ROAs learned from the Validator

show rpki prefix-table
  • Should output a list of ROAs (origin-AS, max-length) like below:

13. For redundancy, It is good to peer with more than one validator. Now, setup another RTR session with the External RPKI validator.

 rpki cache 3323 preference 2

(Optinoal)* if you are lazy to set up your own validator, BKNIX provides public ROA caches for all. Please follow full instruction from this link

 rpki cache 323 preference 2

14. Look at all the valid ROAs learned from the Validator again. Compare the result with with previous task.

15. Let us now try to announce some Invalid routes (or hijack someone's routes).

  • Go ahead and announce routes (refer the ip address plan) that belong to other groups and not from your peers. In the example below, R9 in AS135533 is announcing R13's prefix (AS135537):
ip route null0
router bgp 135533
   address-family ipv4 unicast
   network mask
  • Verify the BGP table on R10 (your eBGP neighbor).
sh bgp ipv4 unicast
  • You will see that the route learned from its neighbor R9.

16. Let us have a look at Not Found routes - routes for which there are no correspnding ROAs (neither valid or invalid, perhaps not created yet). These make up more than 80% of the global routing table, which indicates many people haven't created ROAs for their prefixes!

  • Let us announce special use prefixes (RFC5735), for which there should not be any existing ROAs. Example below for R13 announcing documentation prefix
ip route null0
router bgp 135537
   address-family ipv4 unicast
   network mask
  • For other routers, please feel free to use any prefixes listed in RFC5735 (preferably use Note that if you and your eBGP peer both announce the same prefix, since it is locally originated, it will be marked as Valid.
  • A look at R14's BGP table:

17. We can follow best practice recommendations in RFC7115 to prefer Valids over Not Found or Invalids, and prefer Not Found over Invalid origins.

  • Define a routing policy that prefers Valids > Not Founds > Invalids
route-map ROUTE-VALIDATION permit 10
   match rpki valid
   set local-preference 200
route-map ROUTE-VALIDATION permit 20
   match rpki not-found
   set local-preference 100
route-map ROUTE-VALIDATION permit 30
   match rpki invalid
   set local-preference 50
  • Apply the route-map to inbound updates from your neighbor. Example below for R20:
router bgp 135536
   address-family ipv4 unicast
      neighbor route-map ROUTE-VALIDATION in
  • Now verify the BGP table (example R14 below) to see the policy in action:
sh bgp ipv4 unicast

18. Let us now try to Deny invalid routes. Example below for R14:

route-map ROUTE-VALIDATION deny 30
   match rpki invalid

wunca40-rpki/lab03.txt · Last modified: 2020/01/08 15:00 by admin