[f-nsp] Netiron AS4 capabilities

[Tim Warnock]

So reading all that - if the CER advertises the capability that it can talk "NEW BGP" as per RFC6793 but then barfs on an UPDATE that matches RFC6793 specifications then the bug must be in the CER.

I'm surprised this hasn't been a bigger problem to date, TBH.

What happens if you peer MT:CER with the CER using AS23456.

Does the MT then switch to "OLD BGP" mode?

-----Original Message-----
From: foundry-nsp <foundry-nsp-bounces at puck.nether.net> On Behalf Of Jörg Kost
Sent: Saturday, July 1, 2023 12:09 AM
To: Bogdan-Stefan Rotariu <bogdan at rotariu.ro>
Cc: foundry-nsp at puck.nether.net
Subject: Re: [f-nsp] Netiron AS4 capabilities

There is a difference if you have to read an unsigned int 16 or unsigned eight from the packet stream, and flags are set to 1 by default, which is not found in the standard.

Also, as a counterexample, looking at the FRR open source code ensures that extended flags are only set if used and corresponding integers are read/written.

I'm just afraid that arguing won't help in your case. It is, of course, a great pity that the manufacturer does not seem to care about the interoperability of its device. The handling will then probably also affect other areas and Co. That doesn't look very customer friendly. Luckily you can choose your manufacturer.

Of course, you can also open a ticket with Extreme again if you sign a valid support contract. Which I always appreciate with Brocade and now Extreme; once you get past the first barrier of "do you think it's a bug?", you quickly have contact with support or engineering, who can really familiarize themselves with your problem and ultimately fix it. In addition, there is the first-class release/change log, where every small bug can also be found.

Unfortunately, in the early days of the SLX, we found and reported many "startup" bugs, and everything was always fixed, it's running for good now. And with NetIron systems, we have BGP sessions with 900 days and more uptime...

In this sense:
Buy something good with appropriate support :-)




On 30 Jun 2023, at 14:41, Bogdan-Stefan Rotariu wrote:

> Ok, so, this is te answer from Mikrotik regarding the extended-length.
>
> "extended length" is not really related to this issue. That flag only signals how length value is encoded. "extended length" does not determine on how ASNs are encoded.
>
> Regarding length itself, RFC does not define that extended length attribute MUST not be used when length is less than 255. "MAY" and "MUST" meaning is not the same.
>
_______________________________________________
foundry-nsp mailing list
foundry-nsp at puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp