eclist matching question

[Ondrej Zajicek]

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.


-- 
Elen sila lumenn' omentielvo

Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20200707/e8bf3399/attachment.sig>