On Fri, 13 Jun 2025, at 12:31, André Grüneberg wrote:
As far as I can see RFC9234 does not mandate handling a route leak with Treat-as-widthdraw. It just refers to leaking routes to be ineligible (for further use).
My understanding: a leaked route should be present in Adj-RIB-In, but not into Loc-RIB.
I do understand that Bird does not follow the traditional path of other BGP speakers and has no Adj-RIB-In/Out. In a multi-table route server setup Adj-RIB-In/Out is mimicked by the per-peer-table. In a single-table setup, the leaked route would go into the main table. So the question is: Could you imagine another way (i.e. different from Treat-as-withdraw) of handling "ineligible" routes?
Bird normally operates without Adj-RIB-In, but can be configured to operate with one:
`import table *switch*` A BGP import table contains all received routes from given BGP neighbor, before application of import filters. It is also called *Adj-RIB-In* in BGP terminology. BIRD BGP by default operates without import tables, in which case received routes are just processed by import filters, accepted ones are stored in the master table, and the rest is forgotten. Enabling `import table` allows to store unprocessed routes, which can be examined later by `show route`, and can be used to reconfigure import filters without full route refresh. Default: off.
(I assume this contains routes discarded because of an incorrect OTC attribute but I have not verified this. Even then I'm not sure Bird can (currently) use it to give you information on why routes were filtered) - Erin