Re: [f-nsp] Netiron AS4 capabilities

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 <[email protected]> On Behalf Of J=F6rg=
 Kost
Sent: Saturday, July 1, 2023 12:09 AM
To: Bogdan-Stefan Rotariu <[email protected]>
Cc: [email protected]
Subject: Re: [f-nsp] Netiron AS4 capabilities

There is a difference if you have to read an unsigned int 16 or unsigned ei=
ght 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/wr=
itten.

I'm just afraid that arguing won't help in your case. It is, of course, a g=
reat pity that the manufacturer does not seem to care about the interoperab=
ility of its device. The handling will then probably also affect other area=
s 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 vali=
d 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 qui=
ckly have contact with support or engineering, who can really familiarize t=
hemselves with your problem and ultimately fix it. In addition, there is th=
e 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 "st=
artup" bugs, and everything was always fixed, it's running for good now. An=
d 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 sig=
nals how length value is encoded. "extended length" does not determine on h=
ow ASNs are encoded.
>
> Regarding length itself, RFC does not define that extended length attribu=
te MUST not be used when length is less than 255. "MAY" and "MUST" meaning =
is not the same.
>
_______________________________________________
foundry-nsp mailing list
[email protected]
http://puck.nether.net/mailman/listinfo/foundry-nsp