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.

• 1. 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.

• 2. 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.

• 3. 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.