Sat Dec 30, 2023 1:32 pm
It is a result of the rewrite of the routing protocol engines, where the filtering now has been moved into another process.
This was done to allow the use of more than one core of the CPU. In the v6 days the complaint was that even when you had a 72-core beast of a router, all BGP processing still was done on a single core.
The new routing engine fixes that, because it has options to have each peer connection handled by a different core, and some of the routing tasks done by yet another core.
But apparently (at least in the design they use) that means that filter processing can no longer be done while receiving the routes. All received routes are stored in a table, and then another process marks them as accepted/filtered, and of course yet another process decides which one is active and used for routing.
The "accept NLRI" feature is a bit lacking, because an address list only has entries for (sub)nets, not for prefix length.
A common case would be "I only want to accept the 0.0.0.0/0 route and the routes to these subnets", but once you put 0.0.0.0/0 in the NLRI accept list it accepts EVERYTHING, because all networks match 0.0.0.0/0.
That is something they should fix, e.g. by adding an option "Input accept default route" that you could check when using "Input accept NLRI". Or maybe by having a "not" ("!") option which would not accept but rather would drop anything in the address list.