Missing route that is shown in filter used by eBGP

[Maria Matejka]

Good morning Nico,

On Fri, Nov 21, 2025 at 09:29:12AM +0100, Nico Schottelius wrote:

> thanks for the reply, but I am a bit puzzled, in multiple cases:

Oh that's ok. BIRD is complex.

> - a) active vs. all routes
>   I was under the impression that filtering allows me to select the best
>   route, i.e. filters apply on "all routes", not on "best routes".
> 
>   Shouldn't it be the case that filters in general operate on all, not
>   already filtered routes?

Well, well, yes and no. Filtering on …

- import allows you to select whether a route enters the best route selection process
- export to BGP, Babel, OSPF, RIP, Kernel allows you to select whether the best route passes into the protocol
- export to Pipe and BGP with Add Path TX allows you to select which of
  the routes pass into the protocol, regardless of the best route
  selected
- export to BGP with Secondary option allows you to walk over the route
  list and pick the first route to pass the filter

We expect to add some more options to make this even more powerful, e.g.
an additional filter block after the iBGP nexthop resolution, or maybe
even some customization of best route selection. This should
~~confuse people even more~~ allow people better customization.

With that, if you wish to export to BGP "first which passes", you can
use `secondary` in the channel config. You need a `sorted` table to do
that, iirc.

> - b) filter output vs. export reality
>   Independent of whether we filter on "all best" or "all routes", in the
>   CLI the filter output shown does include the route - if the filter
>   does not match, it also should not print it

Well, if you do `show route filter xyz`, then you get all routes
matching that filter. Some protocols pick them. You can do `show route
export bgp_to_internet.ipv6` to explicitly re-run the export filter in
that context.

I know that it is kinda confusing, and we should probably improve our
documentation to show this properly.

> - Route attribute background
> 
>   Maybe for understanding *why* the route exists as it exists:
> 
>   - Using a match on RTS_STATIC is somewhat universal and can be used in
>     all of our data centers, as *if* we define a static route, we do
>     want to eBGP export it
>   - The main reason why it was defined in this case to be static is to
>     allow the filter to grab it - otherwise it would actually not be
>     needed at all
>   - The main motivation is to reduce the number of special cases for
>     selecting internet facing routes in the same way everywhere

With that, I would simply lower the preference of `protocol direct` then
under 200, maybe to something like 180 which is still more than default
babel but less than static, and that should fix your problem. The direct
protocol default preference is kinda unreasonably high in your case.

> - c) Multi attribute matching
>   So the effective route is seen via direct, static and babel.
>   My assumption in bird would be that I can select (filter) the route
>   using one of the three protocol RTS_ matches to find and export the
>   route.

That is possible with the `sorted` table option and `secondary` bgp
channel option.

>   So what I am trying to say is that as a user I'd expect the union of
>   attributes to be matching and not only the the current/best selected.

Then we failed to set the user expectation correctly.

>   Which seems to be what the filter output in the CLI is doing, versus
>   what bird exports.

Yup, because e.g. Pipe takes all while BGP takes best by default, and
the show route output does not know which export behavior you prefer.
To show only best routes, you can add `primary` to the `show route`
command.

> Does it make sense?

Yes. Welcome to the group of people who got confused by our UI multiple
times! We should definitely make it less confusing for future.

Thanks for all of this, it's a very valuable feedback for us.  
Maria

-- 
Maria Matejka (she/her) | BIRD Team Leader | CZ.NIC, z.s.p.o.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20251121/e4a457c4/attachment.htm>