Re: [f-nsp] Netiron AS4 capabilities
Bogdan Rotariu <[email protected]> Sat, 1 Jul 2023 14:58:57 +0300
| Newsgroups | gmane.network.nsp.foundry |
|---|---|
| Message-ID | <[email protected]> |
--===============4829850623969070839== Content-Type: multipart/alternative; boundary="Apple-Mail=_9C06C2E4-2374-4F9D-BB5D-071D240E7890" --Apple-Mail=_9C06C2E4-2374-4F9D-BB5D-071D240E7890 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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.=E2=80=9D 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=E2=80=99s, I cannot say nothing wrong about Netiron. In the last days I=E2=80=99ve been testing Mikrotik=E2=80=99s 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. > On 30 Jun 2023, at 17:08, J=C3=B6rg Kost <[email protected]> wrote: >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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... >=20 > In this sense: > Buy something good with appropriate support :-) >=20 >=20 >=20 >=20 > On 30 Jun 2023, at 14:41, Bogdan-Stefan Rotariu wrote: >=20 >> Ok, so, this is te answer from Mikrotik regarding the = extended-length. >>=20 >> "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. >>=20 >> 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. >>=20 --Apple-Mail=_9C06C2E4-2374-4F9D-BB5D-071D240E7890 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"overflow-wrap: break-word; = -webkit-nbsp-mode: space; line-break: after-white-space;">Thank you, I = will not argue anymore as there is not so much interest from = Mikrotik.<div>Yes, RR is an option, but a bad RR implementation is worst = than no RR.</div><div><br></div><div>Mikrotik last answer is related to = the BIRD/FRR issue from 2021:</div><div><br></div><div>"<span = style=3D"caret-color: rgb(23, 43, 77); color: rgb(23, 43, 77); = font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", = Roboto, Oxygen, Ubuntu, "Fira Sans", "Droid Sans", = "Helvetica Neue", sans-serif; font-size: 14px;">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.</span>=E2=80=9D</div><div><br></div><div>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=E2=80=99s,= I cannot say nothing wrong about Netiron.</div><div><br></div><div>In = the last days I=E2=80=99ve been testing Mikrotik=E2=80=99s 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.</div><div><br></div><div>Thank you = again for your great interest in this = issue.</div><div><div><br><blockquote type=3D"cite"><div>On 30 Jun 2023, = at 17:08, J=C3=B6rg Kost <[email protected]> wrote:</div><br = class=3D"Apple-interchange-newline"><div><div>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.<br><br>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.<br><br>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.<br><br>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.<br><br>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...<br><br>In this sense:<br>Buy something good with appropriate = support :-)<br><br><br><br><br>On 30 Jun 2023, at 14:41, Bogdan-Stefan = Rotariu wrote:<br><br><blockquote type=3D"cite">Ok, so, this is te = answer from Mikrotik regarding the extended-length.<br><br>"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.<br><br>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.<br><br></blockquote></div></div></blockquote></div><br></div></body>= </html>= --Apple-Mail=_9C06C2E4-2374-4F9D-BB5D-071D240E7890-- --===============4829850623969070839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp --===============4829850623969070839==--