With route validation now operational, this lab explores how to share validation state between iBGP peers.
The diagram below is a reminder of the lab topology:
Network operators would normally set up all EBGP speaking routers with a session talking to the two redundant validators deployed on the network.
For some networks this could end up being a significant number of sessions. Another option would be to distribute the validation state between iBGP peers; a standard extended BGP Community has been defined to allow this. This means that all routers participating in the iBGP mesh can act on the validation state as determined by the routers which have a RTR connection to the validation cache.
We are now going to share the validation state from the Border, Peering and Access routers across the iBGP mesh. We aren’t going to set this up on the Trigger router, as we still need RTBH to work for destinations with potentially different origins from the ones we originate (more later).
To distribute validation state, Cisco IOS has the following two commands:
neighbor <xxxx> send-community both
neighbor <xxxx> announce rpki stateExplaining these two:
send-community both means that the iBGP session will send not only the standard BGP communities but also any defined extended BGP communities. The default send-community command only sends the standard BGP communities (remember that IOS default is to send no communities at all).
announce rpki state means that the router will set the extended BGP community values for valid (0x4300:0:0), unknown (0x4300:0:1) and invalid (0x4300:0:2) as per RFC8097.
The two commands need to be set on all routers, not just the routers with a validator configuration set up on it. The iBGP neighbour receiving the prefixes needs the announce rpki state command as well (even though it is only accepting the extended community indicating the RPKI state).
Now add the above two commands to all the iBGP peer-groups on the Border, Core, Peering and Access Routers. Do not add them to the Trigger Router as that is used only for RTBH - we don’t need to know validation state there.
The Core Router has no configuration connecting it to a validator. If you now display the BGP table, what do you observe?
You should see validation states for the prefixes in the BGP table.
Our final test is to remove the RPKI validator configuration on the Access and Peering Routers. This is just to test the effect of propagating the validation information by the extended BGP community from the Border Router.
On Peering and Access Router, delete the validator line:
router bgp X0
no bgp rpki server tcp 100.68.X.30 port 3323 refresh 3600
no bgp rpki server tcp 10.10.0.241 port 3323 refresh 3600
!Once you have done this, check the BGP tables on all 4 routers in the autonomous system.
What do you see in the BGP table now?
What valid routes to you see?
Do you see any invalid routes now?
Discuss in your group, and with the instructors when this portion of the lab exercise is completed.
This lab has demonstrated how to propagate validation information between iBGP speaking routers in an AS, and showed the results of doing this.
Note: most operators will test validation state on their EBGP speaking routers only. However, some networks can be mostly EBGP speakers, with an IBGP mesh linking them, and to scale these having a validator configuration on only a few of these routers would make more operational sense.