I want to load a BGP peer that is sending me full + default.. I need anything that has its AS ONLY, no transit, to come in but everything else to be discarded. Normally I would create a filter that would accept where AS-PATH=AS# then discard the rest, but in v7 can’t discard the rest? the NLRI don’t help… Thoughts?
What is the correct method of doing this….
On RouterOS 7, if you use filters, what is not accepted is implicity discarded.
If you don’t specify anything ,it still loads it, it is just filtered 
I want those prefixes to be discarded and not loaded into memory at all… not a option in v7?
I’m not one expert on BGP, but why you can not create filters???
I believe he means “discard from memory”. It is not possible, input-nlri and others are used to discard fast, regexps are not fast so are not available as a method to discard bgp update messages directly.
You can only reject with filters.
We could do that in v6
Maybe we need a soft-reconfigure option, i.e. if its turned on as normal, it would function like it does. If we turn it off. A reject will remove it from memory.. ? Would be a simple method of doing it.
What about if in HW.. If I load 2000 routes, the rest are filtered, does 2000 routes get added to HW only?
HW candidate routes can be only active routes and with the HW flag set.
Filtered routes will never be active.
At least in v6 you had the option to discard with filters (instead of only reject).
The accept-nlri is much more limited because it accepts using an address list, and address lists do not have prefix-length.
For this case you would want to accept 0.0.0.0/0 with prefix length 0, but as an address list 0.0.0.0/0 simply accepts everything.
It would be better when accept-nlri would use some dedicated mechanism that is more like the v6 filtering where you can specify a list of items to be accepted or discarded. That would not need to have slow functions like regexp, just a simple list of prefixes with prefix length range. This case could then be written as:
action=accept prefix=0.0.0.0/0 prefix-len=0-0
action=discard
V7 cannot really cope without a discard rule…especially when using peering route servers on non ARM64 based routers…
Its crazy that I have 1m (Many RS servers from difference exchanges) routes in my router that the filters have to pass through each time there is a change, when they could be filtered once and discarded.
You should be able to accept any routes with an AS Path containing only your provider’s AS.
/routing/filter/rule
add chain=myChain rule="if (bgp-as-path 1234) {accept}"
What he (and others above) is worried about is that such a filter rule only prevents the route to become active. It is still put in the table but as “filtered”. That takes up resources.
In v6 such filters would discard the route before it is being stored somewhere.
Can mikrotik consider to re implemented the discard action? As input accept nlri is defined in address list
Hi. I’ve reached this post because i’ve wanted to find a way to negate the access-list for input.accept-nlri. No luck for the moment. The reasoning behind my need is that i have an access-list containing all my local prefixes, and i want them to be discarded from the memory when other eBGP peers advertise them back to me as this is already a best practice. I was hoping to achive this behaviour by using a single access-list. No luck to use something like
input.accept-nlri!=own_prefixes
or
input.accept-nlri not in own_prefixes
yes discard option is not optional features and should return in v7 at least in OSPF if they can’t do it in one sweep and later in BGP, I personally haven’t seen an official response on this with Mikrotik, just wondering why other vendors can do it, what’s so special with ros v7 code base that this important feature can’t be implemented and also if MT is reading this please bring back the routing filter at par with ros v6 or even better, the current routing filter is counter intuitive compare to what we have in v6 just to be honest 
Actually it appears I have misunderstood the “Input accept NLRI” filtering. MikroTik told me the entries in the address list have to be an exact match, so a 0.0.0.0/0 entry only matches the default route.
That makes the entire filter useless for me (I would have wanted to put something like 44.128.0.0/10 into the address list to allow all subnets existing in the 44.128.0.0/10 space) so I did not waste further time on this feature.