On Tue, Jul 07, 2020 at 16:08:02 +0200, Ondrej Zajicek wrote: > On Wed, Jul 01, 2020 at 03:06:30PM +0300, Alexander Shikov wrote: > > On Tue, Jun 30, 2020 at 22:27:54 +0200, Ondrej Zajicek wrote: > > Hello! > > > > bird> show route 109.68.40.0/21 all > > BIRD 1.6.8 ready. > > 109.68.40.0/21 via 193.25.180.17 on bge0 [ITCONS 2020-07-01 15:02:20] * > > (100) [AS25372i] > > Type: BGP unicast univ > > BGP.origin: IGP > > BGP.as_path: 25372 > > BGP.next_hop: 193.25.180.17 > > BGP.local_pref: 100 > > BGP.community: (25372,3) (65005,10804) (31210,31210) > > BGP.ext_community: (rt, 65001, 28773) (rt, 31210, 31210) > > > > bird> show route 109.68.40.0/21 all where (rt,65001,28773) ~ > > bgp_ext_community > > - output is empty, matching failed. > > After investigating, it seems to be caused by ambiguity in extended > communities. There is basic two-octet AS form, which has 2 bytes for ASN > and 4 bytes for local value, and there is extended four-octet AS form > (RFC 5668), which has 4 bytes for ASN and 2 bytes for local value. > > The received community is in the later form, although it has 2B ASN. > While expression '(rt, 65001, 28773)' defines the former form. So they > are two different communities (8B sequences), and do not match. > > We should fix it by having different textual representation for such case > (2B ASN in 4B-ASN form), so it is distinguished from the canonical > represntation.
Dear Ondrej, thank you for investigation and explanation. Just a suggestion, you may consider JunOS representation: target:65001L:28773 vs. target:65001:28773 -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 Mob.: +380 50 410 30 57 http://dtel-ix.net/
