eclist matching question
Hello! I have some strange behavior of list matching operator applied to eclist in v.1.6.3. Example filter function: function test (int peer_as) { if net = 109.68.40.0/21 && peer_as = 28773 then { print "DEBUG2: ", bgp_ext_community; } if (rt,65001,peer_as) ~ bgp_ext_community then { print "DEBUG: Adding one prepend: ", bgp_path.first; bgp_path.prepend(bgp_path.first); } } In log file I see bgp_ext_community attribute which includes (rt,65001,28773) community: Jun 15 15:37:52 <daemon.info> rs1 bird: DEBUG2: (eclist (rt, 65001, 13188) (rt, 65001, 28773) (ro, 31210, 25372)) But the later matching never succeeds, and I don't understand why. Please advice. Thanks! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 Mob.: +380 50 410 30 57 http://dtel-ix.net/
On Mon, Jun 15, 2020 at 15:53:46 +0300, Alexander Shikov wrote:
Hello!
I have some strange behavior of list matching operator applied to eclist in v.1.6.3.
Example filter function:
function test (int peer_as) { if net = 109.68.40.0/21 && peer_as = 28773 then { print "DEBUG2: ", bgp_ext_community; }
if (rt,65001,peer_as) ~ bgp_ext_community then { print "DEBUG: Adding one prepend: ", bgp_path.first; bgp_path.prepend(bgp_path.first); } }
In log file I see bgp_ext_community attribute which includes (rt,65001,28773) community:
Jun 15 15:37:52 <daemon.info> rs1 bird: DEBUG2: (eclist (rt, 65001, 13188) (rt, 65001, 28773) (ro, 31210, 25372))
But the later matching never succeeds, and I don't understand why. Please advice. Thanks!
Hello! The same behavior is in bird v2.0. Can anyone take a look? Thanks! -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 Mob.: +380 50 410 30 57 http://dtel-ix.net/
On Tue, Jun 30, 2020 at 03:39:25PM +0300, Alexander Shikov wrote:
On Mon, Jun 15, 2020 at 15:53:46 +0300, Alexander Shikov wrote:
Hello!
I have some strange behavior of list matching operator applied to eclist in v.1.6.3.
Example filter function:
function test (int peer_as) { if net = 109.68.40.0/21 && peer_as = 28773 then { print "DEBUG2: ", bgp_ext_community; }
if (rt,65001,peer_as) ~ bgp_ext_community then { print "DEBUG: Adding one prepend: ", bgp_path.first; bgp_path.prepend(bgp_path.first); } }
In log file I see bgp_ext_community attribute which includes (rt,65001,28773) community:
Jun 15 15:37:52 <daemon.info> rs1 bird: DEBUG2: (eclist (rt, 65001, 13188) (rt, 65001, 28773) (ro, 31210, 25372))
But the later matching never succeeds, and I don't understand why. Please advice. Thanks!
Hello!
The same behavior is in bird v2.0. Can anyone take a look? Thanks!
Hello Works for me, at least in some similar setups. Could you check if it works for expressions like: bird> show route all where (rt,65001,28773) ~ bgp_ext_community Or (function in config file): function test2(int peer_as) { if (rt,65001,peer_as) ~ bgp_ext_community then { return true; } return false; } bird> show route all where test2(28773) -- Elen sila lumenn' omentielvo Ondrej 'Santiago' Zajicek (email: santiago@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."
On Tue, Jun 30, 2020 at 22:27:54 +0200, Ondrej Zajicek wrote:
Hello
Works for me, at least in some similar setups.
Could you check if it works for expressions like:
bird> show route all where (rt,65001,28773) ~ bgp_ext_community
Or (function in config file):
function test2(int peer_as) { if (rt,65001,peer_as) ~ bgp_ext_community then { return true; } return false; }
bird> show route all where test2(28773)
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. But matching against second value in a ec list works: bird> show route 109.68.40.0/21 all where (rt,31210,31210) ~ bgp_ext_community 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) BGP.large_community: (31210, 31210, 31210) -- Alexander Shikov Technical Staff, Digital Telecom IX Tel.: +380 44 201 14 07 Mob.: +380 50 410 30 57 http://dtel-ix.net/
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@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."
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/
participants (2)
-
Alexander Shikov -
Ondrej Zajicek