[f-nsp] Netiron AS4 capabilities

[Bogdan Rotariu]

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 <jk at ip-clear.de> 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.