Hi Pierre, I think this is well known bug on XE.
We just had a thread week or so back on this list. You need to enable extended community to carry the validation state as otherwise XE considers IBGP learned paths by default as VALID. I think Cisco is already backporting the fixes for this - but as long as you enable ext community state propagation you will be fine. Thx R. On Thu, May 7, 2020 at 10:07 PM Pierre Emeriaud <[email protected]> wrote: > Hello all > > First of all, sorry for the long text wall, but I thin I have a bit of > an interesting issue here. I have a router that announces a prefix > that is not RPKI signed at all, hence sould neither appear valid nor > invalid. > > It _does appear valid_ though on an asr1k running 03.16.06.S. Here is the > setup. > > Said network (44.151.210.0/23) is announced by AS206155 to a transit > operator (AS204092) on two peerings: > - one direct from as206155 (89.234.186.158 - router id 80.67.190.204) > to 204092 ("asbr01" - asr1k - 89.234.186.153) > - one indirect from as206155 (185.1.89.27) to 204092 ("asbr02" - > linux/bird - router id 89.234.186.34) though an IX RS. > - this only happens if peering with asbr02 goes up before asbr01, > otherwise asbr02 prefers the route through asbr01. > > asbr01 and 02 from as204092 are using the same two validators, one > running routinator, the other is using FORT. > > 44.151.210.0/23 is not signed, nor is 44.128.0.0/10. Those prefixes do > not appear as valid in the rpki table: > > asbr01#show ip bgp rpki table | i 44.151.210 > asbr01# > > However the /23 appears signed and hence is prefered: > > asbr01#show ip bgp | be 44.151.21 > N* 44.151.210.0/23 80.67.167.221 20 0 57199 > 34019 3215 206155 i > N* 193.200.43.85 10 0 34019 > 3215 206155 i > N* 89.234.186.158 50 200 0 206155 i > V*>i 185.1.89.27 150 150 0 206155 > i <<< BEST & ROA VALID!? > > asbr01#show ip bgp 44.151.210.0 > BGP routing table entry for 44.151.210.0/23, version 487298116 > BGP Bestpath: deterministic-med: med > Paths: (8 available, best #7, table default) > Advertised to update-groups: > 75 114 118 122 > <snip> > Refresh Epoch 1 > 206155 > 89.234.186.158 from 89.234.186.158 (80.67.190.204) > Origin IGP, metric 50, localpref 200, valid, external > Community: 64496:200 > path 7FA510447288 RPKI State not found <<<< ok, expected. > rx pathid: 0, tx pathid: 0 > Refresh Epoch 1 > 206155, (Received from a RR-client) > 185.1.89.27 (metric 11) from 89.234.186.34 (89.234.186.34) > Origin IGP, metric 150, localpref 150, valid, internal, best > Community: 64496:100 64496:2150 > unknown transitive attribute: flag 0xE0 type 0x20 length 0x18 > value 0003 1D3C 0000 0064 0000 0096 0003 1D3C > 0003 1D3C 0000 0064 > path 7FA51044F508 RPKI State valid <<<<<<< ??? > rx pathid: 0, tx pathid: 0x0 > > The bird on asbr02 do not show the prefix as roa valid: > > bird> show route for 44.151.210.0 all > Table master4: > 44.151.210.0/23 unicast [bgp_breizhix_ipv4 2020-04-30 from > 185.1.89.1] * (100) [AS206155i] > via 185.1.89.27 on enp3s0f0.22 > Type: BGP univ > igp_metric: 20 > BGP.origin: IGP > BGP.as_path: 206155 > BGP.next_hop: 185.1.89.27 > BGP.local_pref: 150 > BGP.community: (64496,100) > BGP.ext_community: (generic, 0x43000000, 0x1) <<< ROA not found > BGP.large_community: (204092, 100, 150) > unicast [bgp_cogent_ipv4 14:13:53.541] (100) > [AS206155i] > > > I've captured the update from asbr02 to asbr01 and there isn't the > 0x43 extended community. However after this first update asbr01 > reflects it to the other ibgp peers _with_ the validation state 0x00! > The capture is available here: https://paste.swordarmor.fr/tHOf > > I'm quite new at RPKI, so I might be missing something entirely, but > the Cisco behaviour looks wrong at best, if not dangerous, as this > makes unsigned prefixes look valid. > > I've skimmed for known rpki bugs on XE and haven't found anything > conclusive, hence my attempt at having more eyeballs looking at this > :) > > What's the list view on this issue? > > thanks > pierre > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
