Thank you for your time and your interest in solving this issue. Your test added light to the issue, I will forward to Mikrotik the information received from you, maybe they will care and do something in the future updates.
Could you please share the patch for FRR so I can replicate the issue with FRR too? > On 1 Jul 2023, at 17:20, Jörg Kost <[email protected]> wrote: > > Well, the weekend is here, and I was able to test and recreate it. > > With MLX, the behavior is like with CER > -> BGP DOWN (Attribute Flags Error) > > On SLX, the behavior is only a warning. > -> received invalid AGGREGATOR attribute flag (0xd0). > -> However, the actual route is installed, and the session stays up. > > To recreate this, I had to actively change the BGP source code of FRR as peer > so that it is forced to set an extending length flag for AGGREGATOR Attribute > and writes a 16-bit value accordingly. > > That's why I give the following verdict :-) > In the name of interoperability when introducing new products and since the > Internet consists of many different manufacturers and devices and when it > comes to peers, the lowest denominator can sometimes be the best, it would be > appropriate to let Mikrotik know to persuade them to do without flagging and > the 16 bits in the aggregator. That's also better before people switch to the > new Mikrotik version and crash a lot of sessions with NetIrons or maybe other > manufacturers. Since the AGGREGATOR attribute has a length 8, an extending > length is unnecessary. > > However, because I also have support for MLX and SLX, I will submit this as a > request when I get a chance. I am sure Extreme will adjust the SLX (different > log?) if necessary, but probably not the behavior for NetIron. > > > On 1 Jul 2023, at 13:58, Bogdan Rotariu wrote: > >> Thank you, I will not argue anymore as there is not so much interest from >> Mikrotik. >> Yes, RR is an option, but a bad RR implementation is worst than no RR. >> >> Mikrotik last answer is related to the BIRD/FRR issue from 2021: >> >> "That bird problem is completely unrelated. They did not use 2bytes for the >> length field when extended length bit was set. RouterOS does not do that, >> length is encoded properly.” >> >> Unfortunately we do not have any support for the CERs and ICXs we have >> within our network since Brocade got split in many pieces so we cannot ask >> Extreme Networks anything regarding CER. We do have 2+ years sessions up the >> CER’s, I cannot say nothing wrong about Netiron. >> >> In the last days I’ve been testing Mikrotik’s CHR 6 release, Junipers vRR, >> Cisco IOS xRV, none of these generate issues to the CER and neither are >> affected by the Mikrotik. The only software in my testing that was affected >> by this is the Netiron, Dell 4032F prints the error and discards the prefix. >> >> Thank you again for your great interest in this issue. _______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
