Hello Mark, hello Jakob,
On Sun, 19 Apr 2020 at 03:03, Mark Tinka <mark.ti...@seacom.mu> wrote: > On 18/Apr/20 16:23, Lukas Tribus wrote: > > > > > More about this issue here: > > https://www.mail-archive.com/nanog@nanog.org/msg104776.html > > > > Code with CSCvc84848 fixed will hopefully ship this summer, until then > > I'm not touching RPKI on IOS(-XE) devices. > > Time to check in with them. So CSCvc84848 actually shipped (in 16.9.6, 16.12.4 and 17.3.2). The change appears to be that IBGP routes are now tagged as "NotFound" as opposed to "Valid". This addresses one specific case, doesn't tackle the root cause and introduces new problems. It is still intervening in the best path selection, even if "prefix-validate allow-invalid" is set, despite the documentation claiming otherwise (see "Use of the Validation State in BGP Best Path Determination" [1]). Only "prefix-validate disable" really disables best path intervention madness (because it basically switches it off). Here's an example of the post-CSCvc84848 behavior: An AS has both a customer and a peer/transit, but not on the same router; also the customer routers are RPKI Valid. Router1 connects to the customer, accepts the RPKI valid routes from the customers and makes them best-path (and announces them in IBGP). Router2 connects to your peer/transit, does not consider the customers routes from Router1, because IBGP routes are NotFound, while the same routes from peer/transit (EBGP) are actually Valid, so the latter become best-path. Before CSCvc84848 the issue was with prefixes not covered by ROA's (IBGP is always Valid, which trump's EBGP NotFound routes, ignoring best-path selection). Now with CSCvc84848 applied, a similar issue exists, just with RPKI Valid routes instead (IBGP is always NotFound, which is trumped by EBGP Valid routes, ignoring best-path selection). I'm assuming this will surprise folks when they bring their networks to post-CSCvc84848 code and suddenly they don't announce their customers' valid prefixes to transits anymore. It would be helpful if the release notes would actually mention CSCvc84848. The only way to avoid messing with the best-path is to disable prefix-validation completely. RPKI Invalids can still be discarded in route-maps, although this disables all the outputs from the BGP table (like whether a route is valid or notfound, which we may still want to know). router bgp ... bgp rpki server tcp [...] address-family ipv4 bgp bestpath prefix-validate disable [...] route-map RM_EBGP_IN deny 10 match rpki invalid route-map RM_EBGP_IN permit 20 [...] Vpnv[46] support and RTR via SSH is still not there. cheers, lukas [1] https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-17/irg-xe-17-book/bgp-origin-as-validation.html _______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/