Re: [f-nsp] Netiron AS4 capabilities

--===============5839906046000688654==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_6221680C-2EC9-45F1-9C6F-13C12A65B4C7"


--Apple-Mail=_6221680C-2EC9-45F1-9C6F-13C12A65B4C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks again J=C3=B6rg for your interest in this issue!

Will answer both questions here, yes, thats me too, I=E2=80=99ve done =
days of testing as we ordered a bunch of Mikrotik=E2=80=99s and the =
Mikrotik support keeps quoting me from RFC=E2=80=99s and I almost got =
convinced that the CER=E2=80=99s are the problem.
Operating at least 160 BGP sessions on the CER=E2=80=99s and we did not =
had any issue before (except memory from time to time). I believe that =
the issue is related just with RouterOS7, tested from at least 7.3 to =
7.10.

We have multiple POP=E2=80=99s and each pop has at least one CER2024 due =
to lack of space and costs of electricity this device is awesome! In =
some cases we need some locations we need a bunch more of 10G ports and =
the CCR2216 specs are insane.

I have used Mikrotik before but not that much, did not wanted to learn =
their CLI but in the end it is not that bad.

So, regarding our setups, each location has at least 1 CER2024 with 1 =
Upstream and some peerings (IX, or other local ISP=E2=80=99s) and each =
location is connected to at least location via OSPF and iBGP (all =
CER=E2=80=99s support MPLS but we did not use it). We share all the =
upstream prefixes between the locations.

In one location where we have 2 CER2024 we want to replace 1 CER2024 =
with a CCR2216 and this would be a simple task, but during the testing =
I=E2=80=99ve found out that it is not that simple due to this issue.

Fort testing I have moved 1 peering and 1 internal link from another =
location to the Mikrotik, did the eBGP with the peering, did OSPF and =
iBGP with our location, till now everything seems to be OK. Sending all =
the prefixes received from upstream by location on the CER2024 to =
Mikrotik works, but when sending the prefixes from that only peering to =
the CER2024, the session closes with "Error: Invalid AGGREGATOR =
attribute length 8=E2=80=9D.

Testing some more so I added the CCR2216 in the middle of two CER=E2=80=99=
s instead of directly connected to the peers:

CER2024 (full table) -> CCR2216 (full table) -> CER2024 - the session =
closes with Error: Invalid AGGREGATOR attribute length 8

I=E2=80=99ve been packet sniffing for some days and see whats going on =
and I am unable to find out really whats the problem, so creating a =
setup in GNS3 where I tried to simulate some routers that aggregate =
prefixes and announce them, unfortunately I was unable to replicate the =
issue in GNS3, most likely is that I cannot feed the full global table =
(or I do not know how)

Moving along I have created some FRR/Quagga machines and send to them =
the prefixes from CCR2216, all good, no errors, sending the prefixes =
that quagga/frr received from CCR2216 to one CER2024, everything works. =
I have tried with or without as4 capability, there is no difference.

Doing some more tests, I have created test iBGP sessions and sent =
prefixes to a Huawei Router, to a Cisco 7600 and a ASR 1001, all of them =
handled the prefixes received from the Mikrotik router.
The only equipment except the CER=E2=80=99s that we tested that had =
issues with the BGP session is a stack of Dell 4032F switches that (I =
think) do not support as4 and their error was:

<187> Jun 18 23:58:11 core-stack-2 BGP[BGP Protocol]: bgpattr.c(1628) =
955741 %% ERR [VRF ""] Received UPDATE from peer x invalid AGGREGATOR =
attribute. Aggregator AS is 65052. Aggregator ID is 0.0.0.0. Resetting =
peer.
<187> Jun 19 00:00:16 core-stack-2 BGP[BGP Protocol]: bgpattr.c(1628) =
955842 %% ERR [VRF ""] Received UPDATE from peer x invalid AGGREGATOR =
attribute. Aggregator AS is 25773. Aggregator ID is 0.0.0.0. Resetting =
peer.

Did not test Mikrotik CHR in a VM, will do that test today but I think =
the outcome is the same.

As for testing needs, a upstream or a full table bgp peer to the =
RouterOS7(CHR VM/HW one) and a Netiron iBGP peer.


> On 29 Jun 2023, at 16:57, J=C3=B6rg Kost <[email protected]> wrote:
>=20
> https://forum.mikrotik.com/viewtopic.php?t=3D197330
>=20
> Is this also from you? :-)
>=20
> Anyway, I checked our network and we have 6.2f, 6.2e and various SLX =
versions. The AGGREGATOR is then also sent here with length=3D8 in =
AS4-capability and accepted by all versions without any issues and =
inserted into the table.
>=20
> So there could be some corner case (bug) between recent RouterOS and =
the CER.
>=20
>=20
> On 29 Jun 2023, at 15:30, J=C3=B6rg Kost wrote:
>=20
>> Hello,
>>=20
>> so the best guess is that the NetIron code is missing the fact that =
it needs to speak 32 bits? But it only occurs since the latest RouterOS =
version? Can it be tested with a Mikrotik VM? Do you have a sample =
version and config about how to quickly adjust it?
>>=20
>> Would like to try it against NetIron and SLX.
>>=20
>> The answer from the manufacturer is of course awesome, in a negative =
sense. The Internet should be a "being together", not an "all against =
all". In that sense, I think it's a pity that they're talking about =
"Hacks and 2007", that sounds a bit unprofessional, even if it were a =
bug on NetIron.
>>=20
>> Greetings
>> J=C3=B6rg
>>=20
>> On 29 Jun 2023, at 14:37, Bogdan-Stefan Rotariu wrote:


--Apple-Mail=_6221680C-2EC9-45F1-9C6F-13C12A65B4C7
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;">Thanks again =
J=C3=B6rg for your interest in this issue!<div><br></div><div>Will =
answer both questions here, yes, thats me too, I=E2=80=99ve done days of =
testing as we ordered a bunch of Mikrotik=E2=80=99s and the Mikrotik =
support keeps quoting me from RFC=E2=80=99s and I almost got convinced =
that the CER=E2=80=99s are the problem.</div><div>Operating at least 160 =
BGP sessions on the CER=E2=80=99s and we did not had any issue before =
(except memory from time to time). I believe that the issue is related =
just with RouterOS7, tested from at least 7.3 to =
7.10.</div><div><br></div><div>We have multiple POP=E2=80=99s and each =
pop has at least one CER2024 due to lack of space and costs of =
electricity this device is awesome! In some cases we need some locations =
we need a bunch more of 10G ports and the CCR2216 specs are =
insane.</div><div><br></div><div>I have used Mikrotik before but not =
that much, did not wanted to learn their CLI but in the end it is not =
that bad.</div><div><br></div><div>So, regarding our setups, each =
location has at least 1 CER2024 with 1 Upstream and some peerings (IX, =
or other local ISP=E2=80=99s) and each location is connected to at least =
location via OSPF and iBGP (all CER=E2=80=99s support MPLS but we did =
not use it). We share all the upstream prefixes between the =
locations.</div><div><br></div><div>In one location where we have 2 =
CER2024 we want to replace 1 CER2024 with a CCR2216 and this would be a =
simple task, but during the testing I=E2=80=99ve found out that it is =
not that simple due to this issue.</div><div><br></div><div>Fort testing =
I have moved 1 peering and 1 internal link from another location to the =
Mikrotik, did the eBGP with the peering, did OSPF and iBGP with our =
location, till now everything seems to be OK. Sending all the prefixes =
received from upstream by location on the CER2024 to Mikrotik works, but =
when sending the prefixes from that only peering to the CER2024, the =
session closes with "Error: Invalid AGGREGATOR attribute length =
8=E2=80=9D.</div><div><br></div><div>Testing some more so I added the =
CCR2216 in the middle of two CER=E2=80=99s instead of directly connected =
to the peers:</div><div><br></div><div>CER2024 (full table) -&gt; =
CCR2216 (full table) -&gt; CER2024 - the session closes with&nbsp;<span =
style=3D"caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Error: Invalid =
AGGREGATOR attribute length 8</span></div><div><span style=3D"caret-color:=
 rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></span></div><div><font =
color=3D"#000000"><span style=3D"caret-color: rgb(0, 0, 0);">I=E2=80=99ve =
been packet sniffing for some days and see whats going on and I am =
unable to find out really whats the problem, so creating a setup in GNS3 =
where I tried to simulate some routers that aggregate prefixes and =
announce them, unfortunately I was unable to replicate the issue in =
GNS3, most likely is that I cannot feed the full global table (or I do =
not know how)</span></font></div><div><font color=3D"#000000"><span =
style=3D"caret-color: rgb(0, 0, 0);"><br></span></font></div><div><font =
color=3D"#000000"><span style=3D"caret-color: rgb(0, 0, 0);">Moving =
along I have created some FRR/Quagga machines and send to them the =
prefixes from CCR2216, all good, no errors, sending the prefixes that =
quagga/frr received from CCR2216 to one CER2024, everything works. I =
have tried with or without as4 capability, there is no =
difference.</span></font></div><div><font color=3D"#000000"><span =
style=3D"caret-color: rgb(0, 0, 0);"><br></span></font></div><div><font =
color=3D"#000000"><span style=3D"caret-color: rgb(0, 0, 0);">Doing some =
more tests, I have created test iBGP sessions and sent prefixes to a =
Huawei Router, to a Cisco 7600 and a ASR 1001, all of them handled the =
prefixes received from the Mikrotik =
router.</span></font></div><div><font color=3D"#000000">The only =
equipment except the CER=E2=80=99s that we tested that had issues with =
the BGP session is a stack of Dell 4032F switches that (I think) do not =
support as4 and their error was:</font></div><div><font =
color=3D"#000000"><br></font></div><div>&lt;187&gt; Jun 18 23:58:11 =
core-stack-2 BGP[BGP Protocol]: bgpattr.c(1628) 955741 %% ERR [VRF ""] =
Received UPDATE from peer x invalid AGGREGATOR attribute. Aggregator AS =
is 65052. Aggregator ID is 0.0.0.0. Resetting =
peer.</div><div>&lt;187&gt; Jun 19 00:00:16 core-stack-2 BGP[BGP =
Protocol]: bgpattr.c(1628) 955842 %% ERR [VRF ""] Received UPDATE from =
peer x invalid AGGREGATOR attribute. Aggregator AS is 25773. Aggregator =
ID is 0.0.0.0. Resetting peer.</div><div><br></div><div>Did not test =
Mikrotik CHR in a VM, will do that test today but I think the outcome is =
the same.</div><div><br></div><div>As for testing needs, a upstream or a =
full table bgp peer to the RouterOS7(CHR VM/HW one) and a Netiron iBGP =
peer.</div><div><br></div><div><div><br><blockquote type=3D"cite"><div>On =
29 Jun 2023, at 16:57, J=C3=B6rg Kost &lt;[email protected]&gt; =
wrote:</div><br =
class=3D"Apple-interchange-newline"><div><div>https://forum.mikrotik.com/v=
iewtopic.php?t=3D197330<br><br>Is this also from you? :-)<br><br>Anyway, =
I checked our network and we have 6.2f, 6.2e and various SLX versions. =
The AGGREGATOR is then also sent here with length=3D8 in AS4-capability =
and accepted by all versions without any issues and inserted into the =
table.<br><br>So there could be some corner case (bug) between recent =
RouterOS and the CER.<br><br><br>On 29 Jun 2023, at 15:30, J=C3=B6rg =
Kost wrote:<br><br><blockquote type=3D"cite">Hello,<br><br>so the best =
guess is that the NetIron code is missing the fact that it needs to =
speak 32 bits? But it only occurs since the latest RouterOS version? Can =
it be tested with a Mikrotik VM? Do you have a sample version and config =
about how to quickly adjust it?<br><br>Would like to try it against =
NetIron and SLX.<br><br>The answer from the manufacturer is of course =
awesome, in a negative sense. The Internet should be a "being together", =
not an "all against all". In that sense, I think it's a pity that =
they're talking about "Hacks and 2007", that sounds a bit =
unprofessional, even if it were a bug on =
NetIron.<br><br>Greetings<br>J=C3=B6rg<br><br>On 29 Jun 2023, at 14:37, =
Bogdan-Stefan Rotariu =
wrote:<br></blockquote></div></div></blockquote></div><br></div></body></h=
tml>=

--Apple-Mail=_6221680C-2EC9-45F1-9C6F-13C12A65B4C7--


--===============5839906046000688654==
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

--===============5839906046000688654==--