Hi,

Got already a ticket at Mikrotik regarding my issue, and during this research I have found that Mikrotik increments by default atomic-aggregate=yes to any announced prefixes.

I am replacing a CER2024 with a Mikrotik, and moving some of the BGP sessions to the Mikrotik. In our setup we have multiple CER2024 that peer each-other with iBGP and Loopbacks with OSPF.

On Mikrotik I have added a few sessions, all seem to work fine until I want to send the received prefixes to our CER2024 and some IPv6 to a Dell L3 stack switch.

Both of equipments complain that there is an issue with aggregator length:

Dell 4032F:
Brocade CER2024:
As at this moment we cannot manipulate any aggregator attribute, it seems strange that I cannot find anyone that has this issue. I had already confirmed that the issue appears in any 7.x versions, tried multiple setups.

FRR/quagga are not affected and tested Cisco 7200 IOS on GNS3, but cannot replicate a a real setup with real bgp feed so I do not know for sure if the issue affects cisco or not.

RFC4271 says that the receiving peer should close the session if he receives invalid attributes, both Dell and Brocade do that, but what I do want to know until a fix is made available by Mikrotik, is anyone else encountering this issue?

It could be old software on remote peer that does not support AS4_AGGREGATOR https://www.rfc-editor.org/rfc/rfc6793

Hey,

Thanks for the answer, I know the support opinion, I'd love to see the community one.
I do strongly believe that the issue is related to Mikrotik, I have done so much testing with this device that I should be paid by Mikrotik for bug bounty rewards and testing.

I'd love to see more implication from Mikrotik and stop thinking that it's the users fault, some of us have a long experience in networking and BGP and used hundreds of equipments.

It is impossible that all of the routers we use can peer the Brocade/Extreme Networks CER2024 and they do that faulty and only Mikrotik follow the rules. As I asked in a ticket, how come we did not encountered any issue with hundreds of peers and tens of internal equipments and by the time we wanted to switch to a Mikrotik (because of availability of ports), the peer between a CER2024 and CCR2216 goes down with invalid AGGGREGATE attribute ?

And during this research I have found out the atomic-aggregate=yes bug that is in ROSv7 since the beginning.

I do accept the irony, but even in a perfect world, Mikrotik should try and play nice with older equipment.

We are talking about a 3K device that we bought to use for BGP and cannot use because it cannot do a simple BGP.
As I see, Mikrotik has a great community that offers their support, the Mikrotik team should appreciate that and try to fix/implement features that affect the working order of other devices and stop trying to redirect us to RFCs.

CER2024 supports AS4 even since we use them, it is a very capable device, within software support and options to enable or disable as4 capabilities. As explained but maybe nobody from Mikrotik reads all the content of a ticket, we are replacing a CER2024 peers with a CCR2216, so, logically, all peers that we had in the CER2024 go into the CCR2216, and everything should be good. But no, prefixes received from upstream by the CCR2216 and sent to CER2024 IBGP peers cause the session to close with "invalid AGGREGATE attribute".

So, why the peers the CER2024 work and what does CCR2216/ROSv7 do to them?

This is from old manual of CER2000 devices:

Hi, did you find a solution (or a work around) to this problem?
We are facing a similar problem on our CCR2216 in combination with a CER2024. In our case the CER closes the session because of an "Attribute Flags Error". It looks like our problems could be related.

Unfortunately, Mikrotik support doesn't even bother to look at our support ticket for days, so I hope to find a solution in this forum...

- Mat

A short update:
Our problems are most likely related. See debug of the Brocade router:

Aug 18 07:52:26.877 BGP: xx.xx.xx.xx received invalid AGGREGATOR attribute flag (0xd0)
Aug 18 07:52:26.877 BGP: xx.xx.xx.xx sending NOTIFICATION 3/4 (Attribute Flags Error)
Aug 18 07:52:26.877 BGP: xx.xx.xx.xx reset due to BGP notification sent
Aug 18 07:52:26.878 BGP: xx.xx.xx.xx Closing TCP connection 0x00000002
Aug 18 07:52:26.878 BGP: xx.xx.xx.xx BGP connection closed

- Mat

Hi,

sorry for the delay. Mikrotik did respond and they have the feature into a todo.

Our solution was to user Route Reflectors, and in the end using RR’s is not a very bad thing.

Unfortunately, we couldn’t peer with one upstream provider who is using Cisco XR(probably an old version) and with another one who is using Cisco7600 with again and older ios. Very hard for a big ISP to upgrade and reload their devices, usually the routers are rebooted when there are critical updates for software or hardware problems.

Mikrotik did fix at least pne of the issue, the issue with the aggregated=yes for any announce prefixes.

During my tests I have tested plenty of Vendors, and I found out that Mikrotik issue is not that bad, as long as it will get an update.

For example, we have a stack of Dell 4032F L3 switches where some of our clients are connected at L3 with BGP. Dell does not filter correctly the management ports, BGP port is wide open in the internet and IPv6 is totally open in the internet as the only workaround would be to make acls on every single interface.

So in the end, if you are using internaly, you can use RR’s, quagga or forks, cisco xrv, bird and any other you may like.

Thank you for the update.
Unfortunately we can't change our network the way you did. Our solution is to remove the brocade routers from our network. They needed to be replaced anyway. Now we have a reason to speed this process up a bit.

- Mat