# 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.
--- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/bgp-rpki/rpki-ibgp-mesh-ibgp-signaling.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.