RPKI iBGP Mesh (iBGP Signaling)

Load rpki.ibgp.mesh.ibgp.signaling.init.cfg

#IOS-XE (R1-R6)
config replace flash:rpki.ibgp.mesh.ibgp.signaling.init.cfg

#IOS-XR (XR1-XR3)
configure
load bootflash:rpki.ibgp.mesh.ibgp.signaling.init.cfg
commit replace
y

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.

Answer

#R2
router bgp 1245
 template peer-policy IBGP
  send-community extended
  announce rpki state
 exit-peer-policy 

#R4, R5
router bgp 1245
 address-family ipv4
  neighbor 2.2.2.2 send-community extended
  neighbor 2.2.2.2 announce rpki state
  neighbor 19.19.19.19 send-community extended
  neighbor 19.19.19.19 announce rpki state
  bgp bestpath prefix-validate allow-invalid
 exit-address-family
 !
 address-family ipv6
  neighbor 2001::2:2:2:2 send-community extended
  neighbor 2001::2:2:2:2 announce rpki state
  neighbor 2001::19:19:19:19 send-community extended
  neighbor 2001::19:19:19:19 announce rpki state
  bgp bestpath prefix-validate allow-invalid

#XR1
router bgp 1245
 address-family ipv4 unicast
  bgp origin-as validation signal ibgp
 !
 address-family ipv6 unicast
  bgp origin-as validation signal ibgp

#XR3
router bgp 1245
 address-family ipv4 unicast
  bgp origin-as validation enable
  bgp bestpath origin-as use validity
  bgp bestpath origin-as allow invalid
 !
 address-family ipv6 unicast
  bgp origin-as validation enable
  bgp bestpath origin-as use validity
  bgp bestpath origin-as allow invalid

Explanation/Verification

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:

#R2
router bgp 1245
 template peer-policy IBGP
  send-community extended
  announce rpki state
 exit-peer-policy 

On IOS-XR, we simply use the following command under the address-family.

#XR1
router bgp 1245
 address-family ipv4 unicast
  bgp origin-as validation signal ibgp
 !
 address-family ipv6 unicast
  bgp origin-as validation signal ibgp

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.

#R4, R5
router bgp 1245
 address-family ipv4
  neighbor 2.2.2.2 send-community extended
  neighbor 2.2.2.2 announce rpki state
  neighbor 19.19.19.19 send-community extended
  neighbor 19.19.19.19 announce rpki state
 exit-address-family
 !
 address-family ipv6
  neighbor 2001::2:2:2:2 send-community extended
  neighbor 2001::2:2:2:2 announce rpki state
  neighbor 2001::19:19:19:19 send-community extended
  neighbor 2001::19:19:19:19 announce rpki state

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.

#R4, R5
router bgp 1245
 address-family ipv4
  bgp bestpath prefix-validate allow-invalid
 !
 address-family ipv6
  bgp bestpath prefix-validate allow-invalid

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.

#XR3
router bgp 1245
 address-family ipv4 unicast
  bgp origin-as validation enable
  bgp bestpath origin-as use validity
  bgp bestpath origin-as allow invalid
 !
 address-family ipv6 unicast
  bgp origin-as validation enable
  bgp bestpath origin-as use validity
  bgp bestpath origin-as allow invalid

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.