I have a CCR1009 which is taking a full BGP feed from my upstream, unfortunately the number of routes in the table makes the router unstable and querying the routing table is slow. My solution in routerOS 6 was to create a filter to only accept the routes I am interested in, this worked extreamly well and the router was rock solid.
In ROS 7 it seems the “reject” action in the filter leaves the routes in memory (but with an “invalid” flag) which again causes the router to be slow and unstable. I am unable to find a statement to completely discard routes on a BGP session, am I missing something?
I would like to vote this up. There should be at least two possibilities to discard/reject learned routes. One could install the routes with status filtered/inactive and the other on should completely ignore the route.
Thanks for the replies guys, I can confirm that passing a prefix list to ’ Accept Input NLRI’ has the desired effect of removing the unwanted prefixes from memory.
I’m looking to drop these “rejected” routes from memory/routing table; however I’m unable to figure out how to do so. We’re only running OSPF, not BGP. Could anyone provide a brief example of how to prevent these rejected routes from showing up in our routing table at all, regardless of it’s “invalid” flag.
You have to use input.accept-nlri for the BGP connection or template (or other input.accept-* options if they work better for your use case). You can’t prevent them from showing up in the routing table using filters.
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.
I hope this functionality can be restored in OSPF at least, this is what set apart from MT to other big brand where dynamic routing protocols is rock solid, another grief is when you have millions of routing entries in routing tables winbox start to crawl well that’s for another day totally unrelated here.
I’m running a lab (eve-ng) to proof the “input.accept-nlri” parameter. I’ve configured “input.accept-nlri=!filtered” in “/routing/bgp/connection” hierarchy, because even the rule matching only the default-route (0.0.0.0/0), any other prefixes are in the memory (“/routing/route print detail where bgp”) classified like filtered. After configure this parameter and refresh the BGP session, neither the filtered prefixes and default-route are
belong the routing table. Anyone have a sintaxe filter example to set in the “input.accpet-nlri” parameter please?
That is great! I think it should have been part of v7 all the time…
Would be even better when it would just accept v6 syntax (exported filters), i.e. “/routing filter add”.