Hi, I just finished changing a Cisco for a CCR1072, and it has not been a pleasant experience.

This CCR has BGP sessions and publishes networks according to filters, we have been fighting for more than 1 hour because the filters were good, we did not find anything that could cause the failure, but some networks were not published with the peers.

We were already crazy and we did not see the fault. Desperately we have restarted the CCR and have published all the networks without missing singular and without having touched anything. Logically we had forwarded, deactivated and re-enabled, even throwing the network interface, but there was no way they would be published.

The filter would be something like this:

chain = null_route prefix = 1.1.66.0 / 24 invert-match = no action = accept set-bgp-prepend-path = ""

chain = null_route prefix = 1.1.67.0 / 24 invert-match = no action = accept set-bgp-prepend-path = ""

chain = null_route prefix = 2.2.44.0 / 22 invert-match = no action = accept set-bgp-prepend-path = ""

chain = null_route prefix = 3.3.132.0 / 22 invert-match = no action = accept set-bgp-prepend-path = ""

chain = null_route invert-match = no action = discard set-bgp-prepend-path = ""

In this case the network 1.1.67 / 24 and 2.2.44 / 22 did not publish them.

It is not the first time that I fight with a rule of this style and simply changing the order has started to work, but today there was no way.

To which you can owe or how to debug this fault, it is a core and I can not restart it because


Best Regards.

I'm not sure I understand what all you said, but one thing I'd like to point out is that logic can get convoluted really quickly if you're using any inverted logic.

A common problem here is this:

"I want to allow 192.0.2.0/24 and 198.51.100.0/24"
Rule 1: action=discard prefix = ! 192.0.2.0/24
Rule 2: action=discard prefix = ! 198.51.100.0/24
Rule 3: action=accept

While this seems correct, it's broken because rule 1 discards anything that is not 192.0.2.0/24 (which would include 198.51.100.0/24), so the only prefix which could reach rule 2 would be 192.0.2.0/24.... which gets discarded by rule 2 because it's not 198.51.100.0/24. And thus nothing can possibly reach rule 3 to get accepted.

The rules you posted are part of a chain which may or may not be getting called from another chain, etc - out of context I cannot say why things aren't working for you, but what I just mentioned here is a common "gotcha"

Thanks for your answer.

I will try to explain it a little better.
I need to announce only a few specific ranges, precisely to avoid making a full bgp upstream.

I first accept a network: 1.1.66.0 / 24
Then I accept another: 1.1.67.0 / 24
One more: 2.2.44.0 / 22
The last: 3.3.132.0 / 22
I deny the rest.

The problem is that the rule being well, it only published the first and the last. The other two do not.

Being sure the rules were fine, all I had left was to restart the CCR. At the time that restarted everything worked correctly, confirming that the rules were correct, but the CCR did not take them into consideration.

Best Regards.

Well, I have seen a bug (and reported it here on the forums and to Mikrotik support directly) where there are cases such that the Mikrotik will fail to withdraw routes from a peer. It will show the route as not being advertised to the peer, but the peer will still have the route. It's somewhat the opposite case from yours, but could be similar.

Mikrotik stated that this will be addressed in routeros v7

If it happens again, try just disabling and re-enabling the peer to see if that fixes the advertisements.

In my case, the rules were fine, and it was shown because at the time that the CCR restarted everything worked as it should, but not before. It was as if the rule had been "cached" and not refreshed.

Logically I did a refresh, resend included I deactivated the peer and I activated it again.

I honestly do not see anything encouraging that they say that problems like these will be treated in RouterOS V7 . I've been listening to V7 since 2015, I think I've remembered and not even one alpha. I understand that someday will come V7, and that completely changes the way of working and you have to start from 0. But I know people that this reason and that everything will be solved in a V7 that has no scheduled date has caused them to change their Cores to other manufacturers because they can not wait for a future that has no date..

Yeah - and their stated reason makes sense.... being that they're re-working the routing engine from scratch.
However, there are threads on here at least as far back as 2012 where Mikrotik states that the fix / feature will be addressed in v7.

I've seen posts where users refer to v7 as a mystic unicorn.

But it's things like this that keep me from even considering Mikrotik in our core network. It's a great piece of CPE that we love very much in that role. But when nebulous little idiosyncratic glitches happen in routing protocols - that's what keeps me from dropping them into the mix anywhere else - and more's the pity because using CCRs would save us so many boat loads of money that I could afford to light my Cuban cigars with $100 bills if we were to switch from Cisco. But I'm running a network that serves hospitals, police departments, municipal phone systems, etc. I'm not going to tell them that their problem will be fixed in version 7.

If it happens again, try just disabling and re-enabling the peer to see if that fixes the advertisements.

In my cases where this bug occurred, only disabling and re-enabling the whole bgp instance would stop those prefixes from being advertised.
This bug exists since RouterOS dropped Quagga and implemented their own BGP. So well over a decade...

It was as if the rule had been "cached" and not refreshed.

There's a bug with the route filters list where you need to disable/enable the filter in question to get it working. This is especially prevalent when creating new filters. It's been this way since forever, to the point that it has become muscle memory nowadays to disable/enable every rule I touch in route filters.

Edit: actually only enabling (even an already enabled) filter makes it work also.

I agree: when you first setup some BGP peers and filters and then start modifying the filters, unpredictable things start
to happen even when you do a refresh or disable/enable the peer. disable/enable the filter usually fixes it, moving
the rule within the filter list also sometimes works. A reboot fixes it as well, of course.
Consider it to be setup trouble, you should not be affected by this once your configuration has stabilized.

I think same that you. BGP is very important protocol in core communications that one simple lost cuestion broken all communication process.

In other time move rules positions solved problem, but this time all are imposibble.

In secondary router no have problem you can reset without problem, but in a communications core this is real problem.

In secondary router no have problem you can reset without problem, but in a communications core this is real problem.

True, but as explained there are workarounds and the problem disappear once you have your configuration OK.
In fact, when you would prepare the entire router before putting it into service you would not encounter this problem.
We sure hope that it will be fixed sometime, but it isn't really critical (at least once you know that it exists).

I found that making any change to the routing filters at all causes RouterOS to re-evaluate the chain on the advertised/received prefixes to/from the peer in question.
This is good behavior. If some prefix now passes a chain where it was once blocked, then an update will be sent to the peer, asserting the new prefix.

But one thing that I found interesting was that changing the order of rules in a chain doesn't cause RouterOS to do so. Interestingly, the "any change at all" statement above even applies to modifying the comments on any rule - even just opening and closing the comment edit window w/o making actual changes would trigger the update. I used this as a work-around whenever the only change to a filter chain was to re-order the existing rules.

Another quirk of ROS's BGP is the fact that making any configuration changes to the peer will cause RouterOS to bounce the peering session entirely (not just send/receive refreshes)... even when the change wouldn't affect actual routing or prefixes at all - such as changing the name of the peer in the configuration. That's definitely . . . sub-optimal behavior.

Alferez's comment is definitely on-point in that this sort of quirkiness is not somethign you should have to tolerate from a piece of core gear doing BGP.