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/