RPKI iBGP Mesh (iBGP Signaling)
Last updated
Last updated
Load rpki.ibgp.mesh.ibgp.signaling.init.cfg
BGP is already fully setup. There is a partial iBGP mesh for AS 1245. (All routers peer only with R2 and XR1).
Configure R2 and XR1 to connect to the RPKI server 10.100.100.1 over TCP/3323. Use validation but allow invalid prefixes.
Currently R4 is preferring the invalid path to 1.1.4.0/22, 1.6.0.0/22, 2001:260::/32 and 2001:288::/32 via R2 instead of the valid path via XR1. Similarly, XR3 prefers invalid paths to XR1 over valid paths to R2. Use iBGP signaling of path validity so that all internal routers will prefer valid paths over invalid paths.
Signaling prefix validation via iBGP is a more elegant way to allow internal routers to use path validation for their bestpath decision process. Note that you can also simply configure the RPKI server on every single internal router. In this case, you would not need to signal path validation, because each router will independently have its own RPKI table from the RPKI server.
iBGP prefix validation signaling uses extcommunities, so we must be able to send extcommunities on IOS-XE. (This is by default enabled for iBGP peers on IOS-XR). On the router that is doing prefix validation, we send-community and announce RPKI state:
On IOS-XR, we simply use the following command under the address-family.
On receiving IOS-XE routers, we need to tell the router to receive the validity state via the iBGP extcommunity. What is slightly confusing, is that the method of doing this is to also enable “annouce rpki state” even though the local router is not annoucing the state, it is receiving the state. This also requires us to enable send-community, even though the router is not sending an extcommunity. This is simply required to enable the “annouce rpki state” command in the first place.
We also must specify that the routers allow invalid prefixes. This is the same process whether the router receives RPKI state from an RPKI server, or from an iBGP peer.
When the iBGP peer is IOS-XR, we simply enable path validation. This is no different than on XR1, except an RPKI server is not defined.
All internal iBGP peers should now have the validity state for all prefixes, and act on them (use the valid state as the bestpath). Shown below is R5 as an example.
Note above that 2001:2a0::/32 has no valid path. This is a special ROA which was included in this lab series to show the meaning of an ROA with AS=0. Examine the ROA for this entry on R2 or XR1. Note that the internal routers do not have a table, since they do not connect to an RPKI server. These routers only receive path validity as an attached extcommunity with each update.
When the origin AS is 0, it means that no announcement is ever valid for this prefix. Essentially, this prefix should never be annouced to the internet. I suppose AS=0 is used because no AS is literally AS 0.
Notice that if we don’t enable invalid routes on the internal routers, such as on R4, this prefix will not be accepted.
