Different behaviour for "show route" with "filtered"?
Good evening, is there a specific reason why there is a different behaviour between show route 209.24.0.0/24 filtered # Works and show route for 209.24.0.0/24 filtered # Doesn't work show route for 209.24.0.3 filtered # Doesn't work in BIRD 2.0.x? Because the following just works (without "filtered"): show route 1.1.1.0/24 show route for 1.1.1.0/24 show route for 1.1.1.1 Based on the syntax show route [<prefix>|for <prefix>|for <ip>] [table <t>] [filter <f>|where <cond>] [all] [primary] [filtered] [(export|preexport|noexport) <p>] [protocol <p>] [stats|count] Show routing table I would expect the same behaviour for with and without "filtered". Or am I overlooking something? Regards, Robert
On Mon, Feb 24, 2020 at 09:25:23PM +0100, Robert Scheck wrote:
Good evening,
is there a specific reason why there is a different behaviour between
show route 209.24.0.0/24 filtered # Works
and
show route for 209.24.0.0/24 filtered # Doesn't work
Hello Works for me: bird> show route filtered Table master4: 10.50.1.0/24 unicast [bgp3 15:36:03.017 from 192.168.4.1] (100/20) [i] via 192.168.14.1 on ve2 10.50.0.0/24 unicast [bgp3 15:36:03.017 from 192.168.4.1] (100/20) [i] via 192.168.14.1 on ve2 10.40.1.0/24 unicast [bgp3 15:36:03.017 from 192.168.4.1] * (100/20) [i] via 192.168.14.1 on ve2 10.40.0.0/24 unicast [bgp3 15:36:03.017 from 192.168.4.1] * (100/20) [i] via 192.168.14.1 on ve2 bird> show route 10.40.0.0/24 Network not found bird> show route 10.40.0.0/24 filtered Table master4: 10.40.0.0/24 unicast [bgp3 15:36:03.017 from 192.168.4.1] * (100/20) [i] via 192.168.14.1 on ve2
show route for 209.24.0.3 filtered # Doesn't work
This does not work as expected, because longest-prefix-match code ('for') checks just existing routes - i.e. it finds best matching prefix with valid routes, and then shows filtered routes on that prefix. That is probably not what users expect. Question is how it should behave - it seems to me that it should do best-match just between filtered routes. Any opinion? -- 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, 25 Feb 2020, Ondrej Zajicek wrote:
On Mon, Feb 24, 2020 at 09:25:23PM +0100, Robert Scheck wrote:
show route for 209.24.0.3 filtered # Doesn't work
This does not work as expected, because longest-prefix-match code ('for') checks just existing routes - i.e. it finds best matching prefix with valid routes, and then shows filtered routes on that prefix. That is probably not what users expect.
Question is how it should behave - it seems to me that it should do best-match just between filtered routes. Any opinion?
My expectation was finding best matching prefix with filtered routes (thus the same behaviour like for valid routes). Regards, Robert
participants (2)
-
Ondrej Zajicek -
Robert Scheck