
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Thanks again Jörg for your interest in this issue!<div><br></div><div>Will answer both questions here, yes, thats me too, I’ve done days of testing as we ordered a bunch of Mikrotik’s and the Mikrotik support keeps quoting me from RFC’s and I almost got convinced that the CER’s are the problem.</div><div>Operating at least 160 BGP sessions on the CER’s 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’s 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’s) and each location is connected to at least location via OSPF and iBGP (all CER’s 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’ve 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”.</div><div><br></div><div>Testing some more so I added the CCR2216 in the middle of two CER’s instead of directly connected to the peers:</div><div><br></div><div>CER2024 (full table) -> CCR2216 (full table) -> CER2024 - the session closes with <span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">Error: Invalid AGGREGATOR attribute length 8</span></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);"><br></span></div><div><font color="#000000"><span style="caret-color: rgb(0, 0, 0);">I’ve 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="#000000"><span style="caret-color: rgb(0, 0, 0);"><br></span></font></div><div><font color="#000000"><span style="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="#000000"><span style="caret-color: rgb(0, 0, 0);"><br></span></font></div><div><font color="#000000"><span style="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="#000000">The only equipment except the CER’s 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="#000000"><br></font></div><div><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.</div><div><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.</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="cite"><div>On 29 Jun 2023, at 16:57, Jörg Kost <jk@ip-clear.de> wrote:</div><br class="Apple-interchange-newline"><div><div>https://forum.mikrotik.com/viewtopic.php?t=197330<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=8 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örg Kost wrote:<br><br><blockquote type="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örg<br><br>On 29 Jun 2023, at 14:37, Bogdan-Stefan Rotariu wrote:<br></blockquote></div></div></blockquote></div><br></div></body></html>