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
