Different behaviour for "show route" with "filtered"?

[Ondrej Zajicek]

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 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."