There's actually an RFC that describes how to propagate the validation state between IBGP speakers. RFC 1897 defines an opaque extended bgp community it has three values mapping on to the three validation States valid not found and invalid these extended communities can be used in ibgp to allow distribution of validation state along with the prefix if desired on Cisco IOS to enable this we need to again pair address family do neighbor the neighbor address announce our PKI state and this will pass on the rpki state to the next router for Juno's there's no such built-in support if you want to propagate the validation state you need to explicitly configure this policy and using these opaque extended communities which is one option are as many operators have been doing prior to RFC 1897 defining their own internal communities to do this now the two important caveats when in propagating validation state the first one is interoperability is the defined opaque extended Community Supported nor vendor equipment in a multi vendor network until recently Juno's would not allow they're required to pay extended communities to be configured at the command line and the second issue is Cisco IOS and Cisco IOS XE behavior iOS adds a step to the best path selection algorithm checking validation state and it checks this validation state before checking local preference and this check prefers valid / not found so let's have a look at these in Juno's the opaque extended community was only supported from most recent Juno's releases as sure on the slide so we now can configure these as policy options and it means that interoperability between Cisco IOS and juniper routers is possible using these three opaque extended communities so check with juniper if you need an updated Juno's release to be able to support this with the support now in place we can now set policy to detect these communities being sent from Cisco IOS or iOS XE routers again under policy options we do the configuration as shown on the slide we look for community rpki invalid which we've already defined and then we can set the validation state in the BGP table likewise for invalid and for unknown and then we can implement our other incoming policies as well then we look at the second instance the second caveat and that is propagating validation state in iOS for example a prefix may be learned via two paths we are two separate ebgp speaking rattles so you have these two routers in your network they talk to the core by bgp but they learn path to a destination via two different directions the slide shows an example from this from the routing security workshop that n SRC offers these three prefixes have two different paths to get to them one path is through a direct peer the other one is through the transit provider in this case one ebgp speaking router talks with a validator the other ebgp speaking router does not do terror or design mistyping whatever may have gone wrong the core router sees these two paths and the best path selection process prefers the valid path over the not found even though the not found path has a higher local preference than the valid path for example and this was the case demonstrated in this workshop the immediate direct peering was across an internet exchange part whereas the valid path was visible only through a transit provider in this case it was the peering route that lost its session with the validator leaving only the border router talking to the upstream provider the border router saw the prefix was valid forwarded that on to the core the peering router had state not found and passed that one on to the core best path selection saw that the valid path via the transit provider was preferred over the not found peering path this could have a pretty serious consequence given the volume of traffic that's currently moving between networks over peering links so carrying on with this example looking at the path detail we see the two routing entries we see one path rpki state valid best path even the local preface 50 and we see the other path state not found not chosen even though the local preference is 200 so do we want to actually propagate validation state operators need to think if this is really desired current standard practice I've seen in most implementations has been that only the ebgp speaking routers have a session with two diverse and redundant validators as I was mentioning earlier geographically separate and using both ipv4 and ipv6 if possible we want to check the validation state on ebgp speaking routers we want to drop invalids on these ebgp speaking routers and distribute the remaining prefixes by bgp by remaining prefixes I mean the valence and the knot farms and we want to avoid propagating validation state at least in Cisco IOS or make sure that ebgp speaking routers never lose the connectivity to the validators so there needs to be a little bit of care in doing the network design and in during that we have appropriate redundancy in place as we do for many man y other aspects of a network.
© Produced by Philip Smith and the Network Startup Resource Center, through the University of Oregon.
Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
This is a human-readable summary of (and not a substitute for) the license. Disclaimer. You are free to: Share — copy and redistribute the material in any medium or format Adapt — remix, transform, and build upon the material The licensor cannot revoke these freedoms as long as you follow the license terms. Under the following terms: Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. NonCommercial — You may not use the material for commercial purposes. No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.