Mailing List Archive

Hello Bogdan,

According to https://www.rfc-editor.org/rfc/rfc4271.html,

"the AGGREGATOR is an attribute of length 6", not 8.

According to https://www.rfc-editor.org/rfc/rfc6793.html,

"the AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered malformed if the attribute length is not 8".

I think it looks like a bug in the Mikrotik BGP code that tries to encode AS4 in an AS attribute.

BR
Jörg


On 29 Jun 2023, at 13:44, Bogdan-Stefan Rotariu wrote:

> Hi there,
>
> We have some CER2024 in our network, and we are starting to encounter issues when receiving prefixes from Mikrotik CCR2216 that is running with ROSv7. Has anyone any ideea except replacing the CER’s?
>
> The peer is has AS4 capability negociated:
>
> Neighbor AS4 Capability Negotiation:
> Peer Negotiated AS4 capability
> Peer configured for AS4 capability
>
> We are running version 6.3.0.fT183:
>
> IronWare : Version 6.3.0fT183 Copyright (c) 2017-2019 Extreme Networks, Inc.
> Compiled on Jul 14 2022 at 21:38:40 labeled as ce06300f
> (18589108 bytes) from Primary
>
> last-packet-with-error decode shows :
>
> Received Message Length: 94
> BGP Message:
> 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x005e0200
> 0x00004340 0x01010050 0x02001602 0x05000022 0x04000015
> 0xe60000ad 0x820000ad 0x820000ad 0x82400304 0x0a0b010f
> 0x40050400 0x00006440 0x0600d008 0x00042204 0x0064d007
> 0x00080000 0xad825509 0x1f8617c3 0xd204
>
> BGP Header
> Marker: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
> Message Length: (0x005e) 94
> Message Type: (0x02) UPDATE
>
> UPDATE Message
> Unfeasible route length: (0x0000) 0
> Update path attributes
> Total Path Attribute length: (0x0043) 67
> Flags : (0x40) Well Known, Transitive, Complete
> Type : (0x01) Origin
> Length: (0x01) 1
> Origin: (0x00) IGP
>
> Flags : (0x50) Well Known, Transitive, Complete, Extended length
> Type : (0x02) AS Path
> Length: (0x0016) 22
> Segment Type : (0x02) AS Sequence
> Segment Length: (0x05) 5
> AS Numbers : (0x0000) 0, (0x2204) 8708, (0x0000) 0, (0x15e6) 5606, (0x0000) 0,
> Segment Type : (0xad) Unknown(173)
> Segment Length: (0x82) 130
> AS Numbers : (0x0000) 0, (0xad82) 44418, (0x0000) 0, (0xad82) 44418,
>
> Flags : (0x40) Well Known, Transitive, Complete
> Type : (0x03) Next Hop
> Length: (0x04) 4
> Next Hop IP address: (0x0a0b010f) 10.11.1.15
>
> Flags : (0x40) Well Known, Transitive, Complete
> Type : (0x05) Local Preference
> Length: (0x04) 4
> Local Preference: (0x00000064) 100
>
> Flags : (0x40) Well Known, Transitive, Complete
> Type : (0x06) Atomic Aggregate
> Length: (0x00) 0
>
> Flags : (0xd0) Optional, Transitive, Complete, Extended length
> Type : (0x08) Community
> Length: (0x0004) 4
> Community List: (0x22040064) 8708:100
>
> Flags : (0xd0) Optional, Transitive, Complete, Extended length
> Type : (0x07) Aggregator
> Length: (0x0008) 8
> Error: Invalid AGGREGATOR attribute length 8
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Thank you Jörg for the quick update.

Yes, I had a few messages with Mikrotik regarding this issue, and they keep saying that the devices are old, and almost I agree with them because I cannot duplicate the issue using Quagga/FRR/Bird and Cisco IOS/XR BGP. That is why I am asking the experts.

Mikrotik said this in their last reply:

"As it was mentioned before, RouterOS sends ASes encoded in 4bytes even if ASN fit in 2bytes because RFC states
"

" A BGP speaker that advertises such a capability to a particular peer, and receives from that peer the advertisement of such a capability, MUST encode AS numbers as four-octet entities in both the AS_PATH attribute and the AGGREGATOR attribute in the updates it sends to the peer and MUST assume that these attributes in the updates received from the peer encode AS numbers as four-octet entities. "

"



No matter you like it or not, that old software on remote peers are not RFC compliant, there were other customers who complained about the same problem, upgrade of this old software fixes the problem.



We will not make hacks just to support software from 2007 that are not current RFC compliant."




> On 29 Jun 2023, at 15:31, Jörg Kost <jk@ip-clear.de> wrote:
>
> Hello Bogdan,
>
> According to https://www.rfc-editor.org/rfc/rfc4271.html,
>
> "the AGGREGATOR is an attribute of length 6", not 8.
>
> According to https://www.rfc-editor.org/rfc/rfc6793.html,
>
> "the AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered malformed if the attribute length is not 8".
>
> I think it looks like a bug in the Mikrotik BGP code that tries to encode AS4 in an AS attribute.
>
> BR
> Jörg
>
>
> On 29 Jun 2023, at 13:44, Bogdan-Stefan Rotariu wrote:
>
>> Hi there,
>>
>> We have some CER2024 in our network, and we are starting to encounter issues when receiving prefixes from Mikrotik CCR2216 that is running with ROSv7. Has anyone any ideea except replacing the CER’s?
>>
>> The peer is has AS4 capability negociated:
>>
>> Neighbor AS4 Capability Negotiation:
>> Peer Negotiated AS4 capability
>> Peer configured for AS4 capability
>>
>> We are running version 6.3.0.fT183:
>>
>> IronWare : Version 6.3.0fT183 Copyright (c) 2017-2019 Extreme Networks, Inc.
>> Compiled on Jul 14 2022 at 21:38:40 labeled as ce06300f
>> (18589108 bytes) from Primary
>>
>> last-packet-with-error decode shows :
>>
>> Received Message Length: 94
>> BGP Message:
>> 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x005e0200
>> 0x00004340 0x01010050 0x02001602 0x05000022 0x04000015
>> 0xe60000ad 0x820000ad 0x820000ad 0x82400304 0x0a0b010f
>> 0x40050400 0x00006440 0x0600d008 0x00042204 0x0064d007
>> 0x00080000 0xad825509 0x1f8617c3 0xd204
>>
>> BGP Header
>> Marker: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
>> Message Length: (0x005e) 94
>> Message Type: (0x02) UPDATE
>>
>> UPDATE Message
>> Unfeasible route length: (0x0000) 0
>> Update path attributes
>> Total Path Attribute length: (0x0043) 67
>> Flags : (0x40) Well Known, Transitive, Complete
>> Type : (0x01) Origin
>> Length: (0x01) 1
>> Origin: (0x00) IGP
>>
>> Flags : (0x50) Well Known, Transitive, Complete, Extended length
>> Type : (0x02) AS Path
>> Length: (0x0016) 22
>> Segment Type : (0x02) AS Sequence
>> Segment Length: (0x05) 5
>> AS Numbers : (0x0000) 0, (0x2204) 8708, (0x0000) 0, (0x15e6) 5606, (0x0000) 0,
>> Segment Type : (0xad) Unknown(173)
>> Segment Length: (0x82) 130
>> AS Numbers : (0x0000) 0, (0xad82) 44418, (0x0000) 0, (0xad82) 44418,
>>
>> Flags : (0x40) Well Known, Transitive, Complete
>> Type : (0x03) Next Hop
>> Length: (0x04) 4
>> Next Hop IP address: (0x0a0b010f) 10.11.1.15
>>
>> Flags : (0x40) Well Known, Transitive, Complete
>> Type : (0x05) Local Preference
>> Length: (0x04) 4
>> Local Preference: (0x00000064) 100
>>
>> Flags : (0x40) Well Known, Transitive, Complete
>> Type : (0x06) Atomic Aggregate
>> Length: (0x00) 0
>>
>> Flags : (0xd0) Optional, Transitive, Complete, Extended length
>> Type : (0x08) Community
>> Length: (0x0004) 4
>> Community List: (0x22040064) 8708:100
>>
>> Flags : (0xd0) Optional, Transitive, Complete, Extended length
>> Type : (0x07) Aggregator
>> Length: (0x0008) 8
>> Error: Invalid AGGREGATOR attribute length 8
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp

From https://datatracker.ietf.org/doc/html/rfc4271#section-9.2.2.2

g) AGGREGATOR (Type Code 7)

AGGREGATOR is an optional transitive attribute of length 6.
The attribute contains the last AS number that formed the
aggregate route (encoded as 2 octets), followed by the IP
address of the BGP speaker that formed the aggregate route
(encoded as 4 octets). This SHOULD be the same address as
the one used for the BGP Identifier of the speaker.

Usage of this attribute is defined in 5.1.7.

I cant easily see anywhere where that definition was extended to support a length of 8 - so this kinda feels like a RouterOS issue rather than the CERs.

Hopefully I have this correct:

0x0064d007 0x00080000
0xad825509 octets - 173 130 85 09 AS21769/AS2910999817 ?
0x1f8617c3 this should be the aggregator IP address 31 129 23 195 ?



-----Original Message-----
From: foundry-nsp <foundry-nsp-bounces@puck.nether.net> On Behalf Of Bogdan-Stefan Rotariu
Sent: Thursday, June 29, 2023 9:45 PM
To: foundry-nsp@puck.nether.net
Subject: [f-nsp] Netiron AS4 capabilities

Hi there,

We have some CER2024 in our network, and we are starting to encounter issues when receiving prefixes from Mikrotik CCR2216 that is running with ROSv7. Has anyone any ideea except replacing the CER’s?

The peer is has AS4 capability negociated:

Neighbor AS4 Capability Negotiation:
Peer Negotiated AS4 capability
Peer configured for AS4 capability

We are running version 6.3.0.fT183:

IronWare : Version 6.3.0fT183 Copyright (c) 2017-2019 Extreme Networks, Inc.
Compiled on Jul 14 2022 at 21:38:40 labeled as ce06300f
(18589108 bytes) from Primary

last-packet-with-error decode shows :

Received Message Length: 94
BGP Message:
0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x005e0200
0x00004340 0x01010050 0x02001602 0x05000022 0x04000015
0xe60000ad 0x820000ad 0x820000ad 0x82400304 0x0a0b010f
0x40050400 0x00006440 0x0600d008 0x00042204 0x0064d007
0x00080000 0xad825509 0x1f8617c3 0xd204

BGP Header
Marker: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
Message Length: (0x005e) 94
Message Type: (0x02) UPDATE

UPDATE Message
Unfeasible route length: (0x0000) 0
Update path attributes
Total Path Attribute length: (0x0043) 67
Flags : (0x40) Well Known, Transitive, Complete
Type : (0x01) Origin
Length: (0x01) 1
Origin: (0x00) IGP

Flags : (0x50) Well Known, Transitive, Complete, Extended length
Type : (0x02) AS Path
Length: (0x0016) 22
Segment Type : (0x02) AS Sequence
Segment Length: (0x05) 5
AS Numbers : (0x0000) 0, (0x2204) 8708, (0x0000) 0, (0x15e6) 5606, (0x0000) 0,
Segment Type : (0xad) Unknown(173)
Segment Length: (0x82) 130
AS Numbers : (0x0000) 0, (0xad82) 44418, (0x0000) 0, (0xad82) 44418,

Flags : (0x40) Well Known, Transitive, Complete
Type : (0x03) Next Hop
Length: (0x04) 4
Next Hop IP address: (0x0a0b010f) 10.11.1.15

Flags : (0x40) Well Known, Transitive, Complete
Type : (0x05) Local Preference
Length: (0x04) 4
Local Preference: (0x00000064) 100

Flags : (0x40) Well Known, Transitive, Complete
Type : (0x06) Atomic Aggregate
Length: (0x00) 0

Flags : (0xd0) Optional, Transitive, Complete, Extended length
Type : (0x08) Community
Length: (0x0004) 4
Community List: (0x22040064) 8708:100

Flags : (0xd0) Optional, Transitive, Complete, Extended length
Type : (0x07) Aggregator
Length: (0x0008) 8
Error: Invalid AGGREGATOR attribute length 8
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Hello,

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?

Would like to try it against NetIron and SLX.

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.

Greetings
Jörg

On 29 Jun 2023, at 14:37, Bogdan-Stefan Rotariu wrote:

> Thank you Jörg for the quick update.
>
> Yes, I had a few messages with Mikrotik regarding this issue, and they keep saying that the devices are old, and almost I agree with them because I cannot duplicate the issue using Quagga/FRR/Bird and Cisco IOS/XR BGP. That is why I am asking the experts.
>
> Mikrotik said this in their last reply:
>
> "As it was mentioned before, RouterOS sends ASes encoded in 4bytes even if ASN fit in 2bytes because RFC states
> "
>
> " A BGP speaker that advertises such a capability to a particular peer, and receives from that peer the advertisement of such a capability, MUST encode AS numbers as four-octet entities in both the AS_PATH attribute and the AGGREGATOR attribute in the updates it sends to the peer and MUST assume that these attributes in the updates received from the peer encode AS numbers as four-octet entities. "
>
> "
>
>
>
> No matter you like it or not, that old software on remote peers are not RFC compliant, there were other customers who complained about the same problem, upgrade of this old software fixes the problem.
>
>
>
> We will not make hacks just to support software from 2007 that are not current RFC compliant."
>
>
>
>
>> On 29 Jun 2023, at 15:31, Jörg Kost <jk@ip-clear.de> wrote:
>>
>> Hello Bogdan,
>>
>> According to https://www.rfc-editor.org/rfc/rfc4271.html,
>>
>> "the AGGREGATOR is an attribute of length 6", not 8.
>>
>> According to https://www.rfc-editor.org/rfc/rfc6793.html,
>>
>> "the AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered malformed if the attribute length is not 8".
>>
>> I think it looks like a bug in the Mikrotik BGP code that tries to encode AS4 in an AS attribute.
>>
>> BR
>> Jörg
>>
>>
>> On 29 Jun 2023, at 13:44, Bogdan-Stefan Rotariu wrote:
>>
>>> Hi there,
>>>
>>> We have some CER2024 in our network, and we are starting to encounter issues when receiving prefixes from Mikrotik CCR2216 that is running with ROSv7. Has anyone any ideea except replacing the CER’s?
>>>
>>> The peer is has AS4 capability negociated:
>>>
>>> Neighbor AS4 Capability Negotiation:
>>> Peer Negotiated AS4 capability
>>> Peer configured for AS4 capability
>>>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

https://forum.mikrotik.com/viewtopic.php?t=197330

Is this also from you? :-)

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.

So there could be some corner case (bug) between recent RouterOS and the CER.


On 29 Jun 2023, at 15:30, Jörg Kost wrote:

> Hello,
>
> 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?
>
> Would like to try it against NetIron and SLX.
>
> 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.
>
> Greetings
> Jörg
>
> On 29 Jun 2023, at 14:37, Bogdan-Stefan Rotariu wrote:
>
>> Thank you Jörg for the quick update.
>>
>> Yes, I had a few messages with Mikrotik regarding this issue, and they keep saying that the devices are old, and almost I agree with them because I cannot duplicate the issue using Quagga/FRR/Bird and Cisco IOS/XR BGP. That is why I am asking the experts.
>>
>> Mikrotik said this in their last reply:
>>
>> "As it was mentioned before, RouterOS sends ASes encoded in 4bytes even if ASN fit in 2bytes because RFC states
>> "
>>
>> " A BGP speaker that advertises such a capability to a particular peer, and receives from that peer the advertisement of such a capability, MUST encode AS numbers as four-octet entities in both the AS_PATH attribute and the AGGREGATOR attribute in the updates it sends to the peer and MUST assume that these attributes in the updates received from the peer encode AS numbers as four-octet entities. "
>>
>> "
>>
>>
>>
>> No matter you like it or not, that old software on remote peers are not RFC compliant, there were other customers who complained about the same problem, upgrade of this old software fixes the problem.
>>
>>
>>
>> We will not make hacks just to support software from 2007 that are not current RFC compliant."
>>
>>
>>
>>
>>> On 29 Jun 2023, at 15:31, Jörg Kost <jk@ip-clear.de> wrote:
>>>
>>> Hello Bogdan,
>>>
>>> According to https://www.rfc-editor.org/rfc/rfc4271.html,
>>>
>>> "the AGGREGATOR is an attribute of length 6", not 8.
>>>
>>> According to https://www.rfc-editor.org/rfc/rfc6793.html,
>>>
>>> "the AS4_AGGREGATOR attribute in an UPDATE message SHALL be considered malformed if the attribute length is not 8".
>>>
>>> I think it looks like a bug in the Mikrotik BGP code that tries to encode AS4 in an AS attribute.
>>>
>>> BR
>>> Jörg
>>>
>>>
>>> On 29 Jun 2023, at 13:44, Bogdan-Stefan Rotariu wrote:
>>>
>>>> Hi there,
>>>>
>>>> We have some CER2024 in our network, and we are starting to encounter issues when receiving prefixes from Mikrotik CCR2216 that is running with ROSv7. Has anyone any ideea except replacing the CER’s?
>>>>
>>>> The peer is has AS4 capability negociated:
>>>>
>>>> Neighbor AS4 Capability Negotiation:
>>>> Peer Negotiated AS4 capability
>>>> Peer configured for AS4 capability
>>>>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Thanks again Jörg for your interest in this issue!

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.
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.

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.

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’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.

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.

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”.

Testing some more so I added the CCR2216 in the middle of two CER’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’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)

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’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:

<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örg Kost <jk@ip-clear.de> wrote:
>
> https://forum.mikrotik.com/viewtopic.php?t=197330
>
> Is this also from you? :-)
>
> 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.
>
> So there could be some corner case (bug) between recent RouterOS and the CER.
>
>
> On 29 Jun 2023, at 15:30, Jörg Kost wrote:
>
>> Hello,
>>
>> 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?
>>
>> Would like to try it against NetIron and SLX.
>>
>> 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.
>>
>> Greetings
>> Jörg
>>
>> On 29 Jun 2023, at 14:37, Bogdan-Stefan Rotariu wrote:

Have you ever debugged the CER and looked at the BGP capability exchange section and updates?

(Caution: CPU spikes may occur when running many sessions)

debug ip bgp neighbor $X
debug ip bgp general
debug ip bgp events
debug ip bgp updates
debug destination ssh/telnet (some other session window)
-> no debug all


On 29 Jun 2023, at 16:48, Bogdan Rotariu wrote:

> Thanks again Jörg for your interest in this issue!
>
> 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.
> 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.
>
> 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.
>
> 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’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.
>
> 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.
>
> 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”.
>
> Testing some more so I added the CCR2216 in the middle of two CER’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’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)
>
> 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’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:
>
> <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.
>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Yes, I did do that so I can filter AS-PATHS, but too many. I just activated again. For not spamming the list too much added just some of the output,, the full output is here: https://pastie.dev/CdnSr8.yaml

[29.06.2023, 8:53:34,297 PM] Jun 29 20:53:34.351 BGP: Incoming TCP connection. peer 10.11.1.15 OKed
[29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: Rcv incoming TCP connection UP. handle a001143a:1b7fadf4, key 0
[29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Connection Collision, connection_up=0
[29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Accept incoming TCP connection from peer, local IP 10.11.1.4
[29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 TCP Connection opened
[29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending MultiProtocol cap, afi/safi=1/1, length 4
[29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending 4-octet ASN cap, asn=56430, length 4
[29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 fbit is 0, for AFI/SAFI 1/1
[29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending Graceful Restart cap, rbit 0, time 120, length 6
[29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending OPEN, My asn=56430 holdTime=90 route_refresh=1 cooperative= 1, restart 1/0
[29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20, My asn 56430, hold_time 180
[29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20
[29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv capability 2, len 0
[29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv 4-octet ASN capability 65, len 4, asn=56430,
[29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv MP_EXT capability 1, len 4, afi/safi=1/1
[29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv Graceful Restart capability 64, len 2, rbit 0, time 0
[29.06.2023, 8:53:34,301 PM] Jun 29 20:53:34.357 BGP: 10.11.1.15 Peer went to ESTABLISHED state

[29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
[29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
[29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 sending NOTIFICATION 3/4 (Attribute Flags Error)
[29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 reset due to BGP notification sent
[29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 Closing TCP connection 0x00000002
[29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 BGP connection closed
[29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer went to IDLE state (Attribute Flags Error)
[29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer already in IDLE state, stays in IDLE state.
[29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: Attribute Error: BGP: 10.11.1.15 rcv UPDATE w/attr: Origin=IGP AS_PATH= AS_SEQ(2) 8708 5606 44418 44418 44418 NextHop=10.11.1.15 LOCAL_PREF=100 ATOMIC_AGGREGATE COMMUNITY=8708:100
[29.06.2023, 8:53:35,544 PM] Jun 29 20:53:35.600 BGP: 10.11.1.15 RIB_out peer reset #RIB_out 0 (safi 0)




> On 29 Jun 2023, at 19:01, Jörg Kost <jk@ip-clear.de> wrote:
>
> Have you ever debugged the CER and looked at the BGP capability exchange section and updates?
>
> (Caution: CPU spikes may occur when running many sessions)
>
> debug ip bgp neighbor $X
> debug ip bgp general
> debug ip bgp events
> debug ip bgp updates
> debug destination ssh/telnet (some other session window)
> -> no debug all
>
>
> On 29 Jun 2023, at 16:48, Bogdan Rotariu wrote:
>
>> Thanks again Jörg for your interest in this issue!
>>
>> 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.
>> 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.
>>
>> 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.
>>
>> 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’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.
>>
>> 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.
>>
>> 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”.
>>
>> Testing some more so I added the CCR2216 in the middle of two CER’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’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)
>>
>> 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’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:
>>
>> <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.
>>


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Oh thank you, well, I'll throw that naively into the room,
the extended length flag for the AGGREGATOR must not be set at all, as the length is fixed at = 8.
Anyone else have an opinion on this? That looks like an error in the Mikrotik code to me.

There was a similar bug with Bird:
https://bird.network.cz/pipermail/bird-users/2021-March/015312.html

On 29 Jun 2023, at 19:59, Bogdan Rotariu wrote:

> Yes, I did do that so I can filter AS-PATHS, but too many. I just activated again. For not spamming the list too much added just some of the output,, the full output is here: https://pastie.dev/CdnSr8.yaml
>
> [29.06.2023, 8:53:34,297 PM] Jun 29 20:53:34.351 BGP: Incoming TCP connection. peer 10.11.1.15 OKed
> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: Rcv incoming TCP connection UP. handle a001143a:1b7fadf4, key 0
> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Connection Collision, connection_up=0
> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Accept incoming TCP connection from peer, local IP 10.11.1.4
> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 TCP Connection opened
> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending MultiProtocol cap, afi/safi=1/1, length 4
> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending 4-octet ASN cap, asn=56430, length 4
> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 fbit is 0, for AFI/SAFI 1/1
> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending Graceful Restart cap, rbit 0, time 120, length 6
> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending OPEN, My asn=56430 holdTime=90 route_refresh=1 cooperative= 1, restart 1/0
> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20, My asn 56430, hold_time 180
> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20
> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv capability 2, len 0
> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv 4-octet ASN capability 65, len 4, asn=56430,
> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv MP_EXT capability 1, len 4, afi/safi=1/1
> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv Graceful Restart capability 64, len 2, rbit 0, time 0
> [29.06.2023, 8:53:34,301 PM] Jun 29 20:53:34.357 BGP: 10.11.1.15 Peer went to ESTABLISHED state
>
> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 sending NOTIFICATION 3/4 (Attribute Flags Error)
> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 reset due to BGP notification sent
> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 Closing TCP connection 0x00000002
> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 BGP connection closed
> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer went to IDLE state (Attribute Flags Error)
> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer already in IDLE state, stays in IDLE state.
> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: Attribute Error: BGP: 10.11.1.15 rcv UPDATE w/attr: Origin=IGP AS_PATH= AS_SEQ(2) 8708 5606 44418 44418 44418 NextHop=10.11.1.15 LOCAL_PREF=100 ATOMIC_AGGREGATE COMMUNITY=8708:100
> [29.06.2023, 8:53:35,544 PM] Jun 29 20:53:35.600 BGP: 10.11.1.15 RIB_out peer reset #RIB_out 0 (safi 0)
>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

By the way, it is also wrongly set in the BGP message for the community attribute, which must be a bug in Mtick.

NetIron BGP code is quite stable, I've never had any problems with it in 10 years. The parser has to be careful when validating the attributes, it's all C code, nobody needs a buffer overflow on their BGP router ;-)

On 29 Jun 2023, at 20:28, Jörg Kost wrote:

> Oh thank you, well, I'll throw that naively into the room,
> the extended length flag for the AGGREGATOR must not be set at all, as the length is fixed at = 8.
> Anyone else have an opinion on this? That looks like an error in the Mikrotik code to me.
>
> There was a similar bug with Bird:
> https://bird.network.cz/pipermail/bird-users/2021-March/015312.html
>
> On 29 Jun 2023, at 19:59, Bogdan Rotariu wrote:
>
>> Yes, I did do that so I can filter AS-PATHS, but too many. I just activated again. For not spamming the list too much added just some of the output,, the full output is here: https://pastie.dev/CdnSr8.yaml
>>
>> [29.06.2023, 8:53:34,297 PM] Jun 29 20:53:34.351 BGP: Incoming TCP connection. peer 10.11.1.15 OKed
>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: Rcv incoming TCP connection UP. handle a001143a:1b7fadf4, key 0
>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Connection Collision, connection_up=0
>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Accept incoming TCP connection from peer, local IP 10.11.1.4
>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 TCP Connection opened
>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending MultiProtocol cap, afi/safi=1/1, length 4
>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending 4-octet ASN cap, asn=56430, length 4
>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 fbit is 0, for AFI/SAFI 1/1
>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending Graceful Restart cap, rbit 0, time 120, length 6
>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending OPEN, My asn=56430 holdTime=90 route_refresh=1 cooperative= 1, restart 1/0
>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20, My asn 56430, hold_time 180
>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20
>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv capability 2, len 0
>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv 4-octet ASN capability 65, len 4, asn=56430,
>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv MP_EXT capability 1, len 4, afi/safi=1/1
>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv Graceful Restart capability 64, len 2, rbit 0, time 0
>> [29.06.2023, 8:53:34,301 PM] Jun 29 20:53:34.357 BGP: 10.11.1.15 Peer went to ESTABLISHED state
>>
>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 sending NOTIFICATION 3/4 (Attribute Flags Error)
>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 reset due to BGP notification sent
>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 Closing TCP connection 0x00000002
>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 BGP connection closed
>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer went to IDLE state (Attribute Flags Error)
>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer already in IDLE state, stays in IDLE state.
>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: Attribute Error: BGP: 10.11.1.15 rcv UPDATE w/attr: Origin=IGP AS_PATH= AS_SEQ(2) 8708 5606 44418 44418 44418 NextHop=10.11.1.15 LOCAL_PREF=100 ATOMIC_AGGREGATE COMMUNITY=8708:100
>> [29.06.2023, 8:53:35,544 PM] Jun 29 20:53:35.600 BGP: 10.11.1.15 RIB_out peer reset #RIB_out 0 (safi 0)
>>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

The issue with the log pasted below is related to AS 44418, which aggregates at least one of their prefixes.

As there is no confidential informations, I can share a dump[1] for the session from the Mikrotik side, I am unable to mirror the CER2024 port, 10.11.1.4 is a Brocade CER2024 and 10.11.1.15 is a Mikrotik CCR2216. In Wireshark I cannot see anything wrong.

[1] https://apackets.com/api/v1/pcaps/public/download/06dfb59469e9d97fb6429baa1f635f71.pcap/bgp-10.pcap


> On 29 Jun 2023, at 15:40, Tim Warnock <timoid@timoid.org> wrote:
>
> From https://datatracker.ietf.org/doc/html/rfc4271#section-9.2.2.2
>
> g) AGGREGATOR (Type Code 7)
>
> AGGREGATOR is an optional transitive attribute of length 6.
> The attribute contains the last AS number that formed the
> aggregate route (encoded as 2 octets), followed by the IP
> address of the BGP speaker that formed the aggregate route
> (encoded as 4 octets). This SHOULD be the same address as
> the one used for the BGP Identifier of the speaker.
>
> Usage of this attribute is defined in 5.1.7.
>
> I cant easily see anywhere where that definition was extended to support a length of 8 - so this kinda feels like a RouterOS issue rather than the CERs.
>
> Hopefully I have this correct:
>
> 0x0064d007 0x00080000
> 0xad825509 octets - 173 130 85 09 AS21769/AS2910999817 ?
> 0x1f8617c3 this should be the aggregator IP address 31 129 23 195 ?
>
>
>
> -----Original Message-----
> From: foundry-nsp <foundry-nsp-bounces@puck.nether.net> On Behalf Of Bogdan-Stefan Rotariu
> Sent: Thursday, June 29, 2023 9:45 PM
> To: foundry-nsp@puck.nether.net
> Subject: [f-nsp] Netiron AS4 capabilities
>
> Hi there,
>
> We have some CER2024 in our network, and we are starting to encounter issues when receiving prefixes from Mikrotik CCR2216 that is running with ROSv7. Has anyone any ideea except replacing the CER’s?
>
> The peer is has AS4 capability negociated:
>
> Neighbor AS4 Capability Negotiation:
> Peer Negotiated AS4 capability
> Peer configured for AS4 capability
>
> We are running version 6.3.0.fT183:
>
> IronWare : Version 6.3.0fT183 Copyright (c) 2017-2019 Extreme Networks, Inc.
> Compiled on Jul 14 2022 at 21:38:40 labeled as ce06300f
> (18589108 bytes) from Primary
>
> last-packet-with-error decode shows :
>
> Received Message Length: 94
> BGP Message:
> 0xffffffff 0xffffffff 0xffffffff 0xffffffff 0x005e0200
> 0x00004340 0x01010050 0x02001602 0x05000022 0x04000015
> 0xe60000ad 0x820000ad 0x820000ad 0x82400304 0x0a0b010f
> 0x40050400 0x00006440 0x0600d008 0x00042204 0x0064d007
> 0x00080000 0xad825509 0x1f8617c3 0xd204
>
> BGP Header
> Marker: 0xffffffff 0xffffffff 0xffffffff 0xffffffff
> Message Length: (0x005e) 94
> Message Type: (0x02) UPDATE
>
> UPDATE Message
> Unfeasible route length: (0x0000) 0
> Update path attributes
> Total Path Attribute length: (0x0043) 67
> Flags : (0x40) Well Known, Transitive, Complete
> Type : (0x01) Origin
> Length: (0x01) 1
> Origin: (0x00) IGP
>
> Flags : (0x50) Well Known, Transitive, Complete, Extended length
> Type : (0x02) AS Path
> Length: (0x0016) 22
> Segment Type : (0x02) AS Sequence
> Segment Length: (0x05) 5
> AS Numbers : (0x0000) 0, (0x2204) 8708, (0x0000) 0, (0x15e6) 5606, (0x0000) 0,
> Segment Type : (0xad) Unknown(173)
> Segment Length: (0x82) 130
> AS Numbers : (0x0000) 0, (0xad82) 44418, (0x0000) 0, (0xad82) 44418,
>
> Flags : (0x40) Well Known, Transitive, Complete
> Type : (0x03) Next Hop
> Length: (0x04) 4
> Next Hop IP address: (0x0a0b010f) 10.11.1.15
>
> Flags : (0x40) Well Known, Transitive, Complete
> Type : (0x05) Local Preference
> Length: (0x04) 4
> Local Preference: (0x00000064) 100
>
> Flags : (0x40) Well Known, Transitive, Complete
> Type : (0x06) Atomic Aggregate
> Length: (0x00) 0
>
> Flags : (0xd0) Optional, Transitive, Complete, Extended length
> Type : (0x08) Community
> Length: (0x0004) 4
> Community List: (0x22040064) 8708:100
>
> Flags : (0xd0) Optional, Transitive, Complete, Extended length
> Type : (0x07) Aggregator
> Length: (0x0008) 8
> Error: Invalid AGGREGATOR attribute length 8
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp

Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
issue and more unfortunately I got my hands on devices I cannot use :-)

> On 30 Jun 2023, at 00:03, Jörg Kost <jk@ip-clear.de> wrote:
>
> By the way, it is also wrongly set in the BGP message for the community attribute, which must be a bug in Mtick.
>
> NetIron BGP code is quite stable, I've never had any problems with it in 10 years. The parser has to be careful when validating the attributes, it's all C code, nobody needs a buffer overflow on their BGP router ;-)
>
> On 29 Jun 2023, at 20:28, Jörg Kost wrote:
>
>> Oh thank you, well, I'll throw that naively into the room,
>> the extended length flag for the AGGREGATOR must not be set at all, as the length is fixed at = 8.
>> Anyone else have an opinion on this? That looks like an error in the Mikrotik code to me.
>>
>> There was a similar bug with Bird:
>> https://bird.network.cz/pipermail/bird-users/2021-March/015312.html
>>
>> On 29 Jun 2023, at 19:59, Bogdan Rotariu wrote:
>>
>>> Yes, I did do that so I can filter AS-PATHS, but too many. I just activated again. For not spamming the list too much added just some of the output,, the full output is here: https://pastie.dev/CdnSr8.yaml
>>>
>>> [29.06.2023, 8:53:34,297 PM] Jun 29 20:53:34.351 BGP: Incoming TCP connection. peer 10.11.1.15 OKed
>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: Rcv incoming TCP connection UP. handle a001143a:1b7fadf4, key 0
>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Connection Collision, connection_up=0
>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Accept incoming TCP connection from peer, local IP 10.11.1.4
>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 TCP Connection opened
>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending MultiProtocol cap, afi/safi=1/1, length 4
>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending 4-octet ASN cap, asn=56430, length 4
>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 fbit is 0, for AFI/SAFI 1/1
>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending Graceful Restart cap, rbit 0, time 120, length 6
>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending OPEN, My asn=56430 holdTime=90 route_refresh=1 cooperative= 1, restart 1/0
>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20, My asn 56430, hold_time 180
>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20
>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv capability 2, len 0
>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv 4-octet ASN capability 65, len 4, asn=56430,
>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv MP_EXT capability 1, len 4, afi/safi=1/1
>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv Graceful Restart capability 64, len 2, rbit 0, time 0
>>> [29.06.2023, 8:53:34,301 PM] Jun 29 20:53:34.357 BGP: 10.11.1.15 Peer went to ESTABLISHED state
>>>
>>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
>>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
>>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 sending NOTIFICATION 3/4 (Attribute Flags Error)
>>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 reset due to BGP notification sent
>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 Closing TCP connection 0x00000002
>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 BGP connection closed
>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer went to IDLE state (Attribute Flags Error)
>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer already in IDLE state, stays in IDLE state.
>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: Attribute Error: BGP: 10.11.1.15 rcv UPDATE w/attr: Origin=IGP AS_PATH= AS_SEQ(2) 8708 5606 44418 44418 44418 NextHop=10.11.1.15 LOCAL_PREF=100 ATOMIC_AGGREGATE COMMUNITY=8708:100
>>> [29.06.2023, 8:53:35,544 PM] Jun 29 20:53:35.600 BGP: 10.11.1.15 RIB_out peer reset #RIB_out 0 (safi 0)
>>>


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Bottom line: Vote with your wallet, buy some Extreme ;-)

In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
I think that the spontaneously flag setting, will cause problems for other vendors too.

Path Attribute - AS_PATH: empty
Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
0... .... = Optional: Not set
.1.. .... = Transitive: Set
..0. .... = Partial: Not set
...1 .... = Extended-Length: Set
.... 0000 = Unused: 0x0
Type Code: AS_PATH (2)
Length: 0


On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:

> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
> issue and more unfortunately I got my hands on devices I cannot use :-)
>
>> On 30 Jun 2023, at 00:03, Jörg Kost <jk@ip-clear.de> wrote:
>>
>> By the way, it is also wrongly set in the BGP message for the community attribute, which must be a bug in Mtick.
>>
>> NetIron BGP code is quite stable, I've never had any problems with it in 10 years. The parser has to be careful when validating the attributes, it's all C code, nobody needs a buffer overflow on their BGP router ;-)
>>
>> On 29 Jun 2023, at 20:28, Jörg Kost wrote:
>>
>>> Oh thank you, well, I'll throw that naively into the room,
>>> the extended length flag for the AGGREGATOR must not be set at all, as the length is fixed at = 8.
>>> Anyone else have an opinion on this? That looks like an error in the Mikrotik code to me.
>>>
>>> There was a similar bug with Bird:
>>> https://bird.network.cz/pipermail/bird-users/2021-March/015312.html
>>>
>>> On 29 Jun 2023, at 19:59, Bogdan Rotariu wrote:
>>>
>>>> Yes, I did do that so I can filter AS-PATHS, but too many. I just activated again. For not spamming the list too much added just some of the output,, the full output is here: https://pastie.dev/CdnSr8.yaml
>>>>
>>>> [29.06.2023, 8:53:34,297 PM] Jun 29 20:53:34.351 BGP: Incoming TCP connection. peer 10.11.1.15 OKed
>>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: Rcv incoming TCP connection UP. handle a001143a:1b7fadf4, key 0
>>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Connection Collision, connection_up=0
>>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 Accept incoming TCP connection from peer, local IP 10.11.1.4
>>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 TCP Connection opened
>>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending MultiProtocol cap, afi/safi=1/1, length 4
>>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending 4-octet ASN cap, asn=56430, length 4
>>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 fbit is 0, for AFI/SAFI 1/1
>>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending Graceful Restart cap, rbit 0, time 120, length 6
>>>> [29.06.2023, 8:53:34,299 PM] Jun 29 20:53:34.352 BGP: 10.11.1.15 sending OPEN, My asn=56430 holdTime=90 route_refresh=1 cooperative= 1, restart 1/0
>>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20, My asn 56430, hold_time 180
>>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv OPEN w/Option parameter length 20
>>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv capability 2, len 0
>>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv 4-octet ASN capability 65, len 4, asn=56430,
>>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv MP_EXT capability 1, len 4, afi/safi=1/1
>>>> [29.06.2023, 8:53:34,300 PM] Jun 29 20:53:34.355 BGP: 10.11.1.15 rcv Graceful Restart capability 64, len 2, rbit 0, time 0
>>>> [29.06.2023, 8:53:34,301 PM] Jun 29 20:53:34.357 BGP: 10.11.1.15 Peer went to ESTABLISHED state
>>>>
>>>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
>>>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 received invalid AGGREGATOR attribute flag (0xd0)
>>>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 sending NOTIFICATION 3/4 (Attribute Flags Error)
>>>> [29.06.2023, 8:53:35,495 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 reset due to BGP notification sent
>>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.549 BGP: 10.11.1.15 Closing TCP connection 0x00000002
>>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 BGP connection closed
>>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer went to IDLE state (Attribute Flags Error)
>>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: 10.11.1.15 Peer already in IDLE state, stays in IDLE state.
>>>> [29.06.2023, 8:53:35,496 PM] Jun 29 20:53:35.550 BGP: Attribute Error: BGP: 10.11.1.15 rcv UPDATE w/attr: Origin=IGP AS_PATH= AS_SEQ(2) 8708 5606 44418 44418 44418 NextHop=10.11.1.15 LOCAL_PREF=100 ATOMIC_AGGREGATE COMMUNITY=8708:100
>>>> [29.06.2023, 8:53:35,544 PM] Jun 29 20:53:35.600 BGP: 10.11.1.15 RIB_out peer reset #RIB_out 0 (safi 0)
>>>>
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Ty, during my research I have found out that Mikrotik forces atomic-aggregate attribute to any announced prefixes, I guess the extended-length: set comes from that? This bug they acknowledge but said it has nothing to do with my issue and its just Brocade fault.

> On 30 Jun 2023, at 00:27, Jörg Kost <jk@ip-clear.de> wrote:
>
> Bottom line: Vote with your wallet, buy some Extreme ;-)
>
> In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
> I think that the spontaneously flag setting, will cause problems for other vendors too.
>
> Path Attribute - AS_PATH: empty
> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
> 0... .... = Optional: Not set
> .1.. .... = Transitive: Set
> ..0. .... = Partial: Not set
> ...1 .... = Extended-Length: Set
> .... 0000 = Unused: 0x0
> Type Code: AS_PATH (2)
> Length: 0
>
>
> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>
>> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
>> issue and more unfortunately I got my hands on devices I cannot use :-)
>>


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Ok, I can totally replicate the issue using Mikrotik's CHR latest 7.11beta2. Session between a CHR and a CER2024 closes with same error "Error: Invalid AGGREGATOR attribute length 8”. If anyone would like to do a test I would appreciate that.

> On 30 Jun 2023, at 00:50, Bogdan Rotariu <bogdan@rotariu.ro> wrote:
>
> Ty, during my research I have found out that Mikrotik forces atomic-aggregate attribute to any announced prefixes, I guess the extended-length: set comes from that? This bug they acknowledge but said it has nothing to do with my issue and its just Brocade fault.
>
>> On 30 Jun 2023, at 00:27, Jörg Kost <jk@ip-clear.de> wrote:
>>
>> Bottom line: Vote with your wallet, buy some Extreme ;-)
>>
>> In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
>> I think that the spontaneously flag setting, will cause problems for other vendors too.
>>
>> Path Attribute - AS_PATH: empty
>> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
>> 0... .... = Optional: Not set
>> .1.. .... = Transitive: Set
>> ..0. .... = Partial: Not set
>> ...1 .... = Extended-Length: Set
>> .... 0000 = Unused: 0x0
>> Type Code: AS_PATH (2)
>> Length: 0
>>
>>
>> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>>
>>> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
>>> issue and more unfortunately I got my hands on devices I cannot use :-)
>>>
>


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Is this setup only for routes you're originating from the MikroTik or is there full tables being passed on as well?

-----Original Message-----
From: foundry-nsp <foundry-nsp-bounces@puck.nether.net> On Behalf Of Bogdan Rotariu
Sent: Friday, June 30, 2023 8:42 AM
To: foundry-nsp@puck.nether.net
Subject: Re: [f-nsp] Netiron AS4 capabilities

Ok, I can totally replicate the issue using Mikrotik's CHR latest 7.11beta2. Session between a CHR and a CER2024 closes with same error "Error: Invalid AGGREGATOR attribute length 8”. If anyone would like to do a test I would appreciate that.

> On 30 Jun 2023, at 00:50, Bogdan Rotariu <bogdan@rotariu.ro> wrote:
>
> Ty, during my research I have found out that Mikrotik forces atomic-aggregate attribute to any announced prefixes, I guess the extended-length: set comes from that? This bug they acknowledge but said it has nothing to do with my issue and its just Brocade fault.
>
>> On 30 Jun 2023, at 00:27, Jörg Kost <jk@ip-clear.de> wrote:
>>
>> Bottom line: Vote with your wallet, buy some Extreme ;-)
>>
>> In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
>> I think that the spontaneously flag setting, will cause problems for other vendors too.
>>
>> Path Attribute - AS_PATH: empty
>> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
>> 0... .... = Optional: Not set
>> .1.. .... = Transitive: Set
>> ..0. .... = Partial: Not set
>> ...1 .... = Extended-Length: Set
>> .... 0000 = Unused: 0x0
>> Type Code: AS_PATH (2)
>> Length: 0
>>
>>
>> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>>
>>> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
>>> issue and more unfortunately I got my hands on devices I cannot use :-)
>>>
>


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

I see, however, you won't be able to solve it any other way than

1.) Open a new bug report with extended-length at Mikrotik (or use older firmware?)
or
2.) Use a route reflector, which takes the communication between the routers.

There's no point in flagging if the length, for example, can be represented as fixed with 8 bits, or is even set to 0. So there is conflicting information in the BGP message and therefore an Attributes Length or Attributed Data error is thrown. Or do I miss something?

IMHO, the Brocade/Extreme Device protects you from reading "out-of-bounds" and implements the RFC correctly. Otherwise these would be classic exploitable buffer overflow conditions.

https://datatracker.ietf.org/doc/html/rfc1771 used to be much more striking: "Extended Length may be used only if the length of the attribute
value is greater than 255 octets."

While https://www.rfc-editor.org/rfc/rfc4271.html says:
If the Extended Length bit of the Attribute Flags octet is set
to 1, the third and fourth octets of the path attribute contain
the length of the attribute data in octets.



On 30 Jun 2023, at 0:41, Bogdan Rotariu wrote:

> Ok, I can totally replicate the issue using Mikrotik's CHR latest 7.11beta2. Session between a CHR and a CER2024 closes with same error "Error: Invalid AGGREGATOR attribute length 8”. If anyone would like to do a test I would appreciate that.
>
>> On 30 Jun 2023, at 00:50, Bogdan Rotariu <bogdan@rotariu.ro> wrote:
>>
>> Ty, during my research I have found out that Mikrotik forces atomic-aggregate attribute to any announced prefixes, I guess the extended-length: set comes from that? This bug they acknowledge but said it has nothing to do with my issue and its just Brocade fault.
>>
>>> On 30 Jun 2023, at 00:27, Jörg Kost <jk@ip-clear.de> wrote:
>>>
>>> Bottom line: Vote with your wallet, buy some Extreme ;-)
>>>
>>> In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
>>> I think that the spontaneously flag setting, will cause problems for other vendors too.
>>>
>>> Path Attribute - AS_PATH: empty
>>> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
>>> 0... .... = Optional: Not set
>>> .1.. .... = Transitive: Set
>>> ..0. .... = Partial: Not set
>>> ...1 .... = Extended-Length: Set
>>> .... 0000 = Unused: 0x0
>>> Type Code: AS_PATH (2)
>>> Length: 0
>>>
>>>
>>> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>>>
>>>> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
>>>> issue and more unfortunately I got my hands on devices I cannot use :-)
>>>>
>>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

The issue is related at this moment just with prefixes that we receive from peers that are agregated, full bgp table or partial table that contain aggregated prefixes are generating this issue.

> On 30 Jun 2023, at 04:12, Tim Warnock <timoid@timoid.org> wrote:
>
> Is this setup only for routes you're originating from the MikroTik or is there full tables being passed on as well?
>
> -----Original Message-----
> From: foundry-nsp <foundry-nsp-bounces@puck.nether.net> On Behalf Of Bogdan Rotariu
> Sent: Friday, June 30, 2023 8:42 AM
> To: foundry-nsp@puck.nether.net
> Subject: Re: [f-nsp] Netiron AS4 capabilities
>
> Ok, I can totally replicate the issue using Mikrotik's CHR latest 7.11beta2. Session between a CHR and a CER2024 closes with same error "Error: Invalid AGGREGATOR attribute length 8”. If anyone would like to do a test I would appreciate that.
>
>> On 30 Jun 2023, at 00:50, Bogdan Rotariu <bogdan@rotariu.ro> wrote:
>>
>> Ty, during my research I have found out that Mikrotik forces atomic-aggregate attribute to any announced prefixes, I guess the extended-length: set comes from that? This bug they acknowledge but said it has nothing to do with my issue and its just Brocade fault.
>>
>>> On 30 Jun 2023, at 00:27, Jörg Kost <jk@ip-clear.de> wrote:
>>>
>>> Bottom line: Vote with your wallet, buy some Extreme ;-)
>>>
>>> In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
>>> I think that the spontaneously flag setting, will cause problems for other vendors too.
>>>
>>> Path Attribute - AS_PATH: empty
>>> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
>>> 0... .... = Optional: Not set
>>> .1.. .... = Transitive: Set
>>> ..0. .... = Partial: Not set
>>> ...1 .... = Extended-Length: Set
>>> .... 0000 = Unused: 0x0
>>> Type Code: AS_PATH (2)
>>> Length: 0
>>>
>>>
>>> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>>>
>>>> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
>>>> issue and more unfortunately I got my hands on devices I cannot use :-)
>>>>
>>
>
>
> _______________________________________________
> foundry-nsp mailing list
> foundry-nsp@puck.nether.net
> http://puck.nether.net/mailman/listinfo/foundry-nsp


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

Just received a reponse from the Mikrotik ticket:

"RFC 6793 updates RFC4271 where Section 4.1 states
"
A BGP speaker that advertises such a capability to a particular peer,
and receives from that peer the advertisement of such a capability,
MUST encode AS numbers as four-octet entities in both the AS_PATH
attribute and the AGGREGATOR attribute in the updates it sends to the
peer and MUST assume that these attributes in the updates received
from the peer encode AS numbers as four-octet entities.
"

AS4_AGGREGATOR does not apply here in this case because both speakers are considered "NEW BGP Speakers"

Section 3 states what is "NEW Speaker" and what is "OLD Speaker”

"

> On 30 Jun 2023, at 10:44, Jörg Kost <jk@ip-clear.de> wrote:
>
> I see, however, you won't be able to solve it any other way than
>
> 1.) Open a new bug report with extended-length at Mikrotik (or use older firmware?)
> or
> 2.) Use a route reflector, which takes the communication between the routers.
>
> There's no point in flagging if the length, for example, can be represented as fixed with 8 bits, or is even set to 0. So there is conflicting information in the BGP message and therefore an Attributes Length or Attributed Data error is thrown. Or do I miss something?
>
> IMHO, the Brocade/Extreme Device protects you from reading "out-of-bounds" and implements the RFC correctly. Otherwise these would be classic exploitable buffer overflow conditions.
>
> https://datatracker.ietf.org/doc/html/rfc1771 used to be much more striking: "Extended Length may be used only if the length of the attribute
> value is greater than 255 octets."
>
> While https://www.rfc-editor.org/rfc/rfc4271.html says:
> If the Extended Length bit of the Attribute Flags octet is set
> to 1, the third and fourth octets of the path attribute contain
> the length of the attribute data in octets.
>
>
>
> On 30 Jun 2023, at 0:41, Bogdan Rotariu wrote:
>
>> Ok, I can totally replicate the issue using Mikrotik's CHR latest 7.11beta2. Session between a CHR and a CER2024 closes with same error "Error: Invalid AGGREGATOR attribute length 8”. If anyone would like to do a test I would appreciate that.
>>
>>> On 30 Jun 2023, at 00:50, Bogdan Rotariu <bogdan@rotariu.ro> wrote:
>>>
>>> Ty, during my research I have found out that Mikrotik forces atomic-aggregate attribute to any announced prefixes, I guess the extended-length: set comes from that? This bug they acknowledge but said it has nothing to do with my issue and its just Brocade fault.
>>>
>>>> On 30 Jun 2023, at 00:27, Jörg Kost <jk@ip-clear.de> wrote:
>>>>
>>>> Bottom line: Vote with your wallet, buy some Extreme ;-)
>>>>
>>>> In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
>>>> I think that the spontaneously flag setting, will cause problems for other vendors too.
>>>>
>>>> Path Attribute - AS_PATH: empty
>>>> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
>>>> 0... .... = Optional: Not set
>>>> .1.. .... = Transitive: Set
>>>> ..0. .... = Partial: Not set
>>>> ...1 .... = Extended-Length: Set
>>>> .... 0000 = Unused: 0x0
>>>> Type Code: AS_PATH (2)
>>>> Length: 0
>>>>
>>>>
>>>> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>>>>
>>>>> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
>>>>> issue and more unfortunately I got my hands on devices I cannot use :-)
>>>>>
>>>
>>
>>
>> _______________________________________________
>> foundry-nsp mailing list
>> foundry-nsp@puck.nether.net
>> http://puck.nether.net/mailman/listinfo/foundry-nsp

Yes, that also works without any problems, otherwise we would all have issues with our devices for years ;-) - please point out the extended-length. As a workaround, have you turned off as4 capability only for the neighbor Mikrotik router from CER configuration? Would be worth an idea. The problem doesn't seem to be related to AS4 Capability causally, but maybe this changes the flagging of the attribute on Mikrotik router.

On 30 Jun 2023, at 10:52, Bogdan Rotariu wrote:

> Just received a reponse from the Mikrotik ticket:
>
> "RFC 6793 updates RFC4271 where Section 4.1 states
> "
> A BGP speaker that advertises such a capability to a particular peer,
> and receives from that peer the advertisement of such a capability,
> MUST encode AS numbers as four-octet entities in both the AS_PATH
> attribute and the AGGREGATOR attribute in the updates it sends to the
> peer and MUST assume that these attributes in the updates received
> from the peer encode AS numbers as four-octet entities.
> "
>
> AS4_AGGREGATOR does not apply here in this case because both speakers are considered "NEW BGP Speakers"
>
> Section 3 states what is "NEW Speaker" and what is "OLD Speaker”
>
> "
>
>> On 30 Jun 2023, at 10:44, Jörg Kost <jk@ip-clear.de> wrote:
>>
>> I see, however, you won't be able to solve it any other way than
>>
>> 1.) Open a new bug report with extended-length at Mikrotik (or use older firmware?)
>> or
>> 2.) Use a route reflector, which takes the communication between the routers.
>>
>> There's no point in flagging if the length, for example, can be represented as fixed with 8 bits, or is even set to 0. So there is conflicting information in the BGP message and therefore an Attributes Length or Attributed Data error is thrown. Or do I miss something?
>>
>> IMHO, the Brocade/Extreme Device protects you from reading "out-of-bounds" and implements the RFC correctly. Otherwise these would be classic exploitable buffer overflow conditions.
>>
>> https://datatracker.ietf.org/doc/html/rfc1771 used to be much more striking: "Extended Length may be used only if the length of the attribute
>> value is greater than 255 octets."
>>
>> While https://www.rfc-editor.org/rfc/rfc4271.html says:
>> If the Extended Length bit of the Attribute Flags octet is set
>> to 1, the third and fourth octets of the path attribute contain
>> the length of the attribute data in octets.
>>
>>
>>
>> On 30 Jun 2023, at 0:41, Bogdan Rotariu wrote:
>>
>>> Ok, I can totally replicate the issue using Mikrotik's CHR latest 7.11beta2. Session between a CHR and a CER2024 closes with same error "Error: Invalid AGGREGATOR attribute length 8”. If anyone would like to do a test I would appreciate that.
>>>
>>>> On 30 Jun 2023, at 00:50, Bogdan Rotariu <bogdan@rotariu.ro> wrote:
>>>>
>>>> Ty, during my research I have found out that Mikrotik forces atomic-aggregate attribute to any announced prefixes, I guess the extended-length: set comes from that? This bug they acknowledge but said it has nothing to do with my issue and its just Brocade fault.
>>>>
>>>>> On 30 Jun 2023, at 00:27, Jörg Kost <jk@ip-clear.de> wrote:
>>>>>
>>>>> Bottom line: Vote with your wallet, buy some Extreme ;-)
>>>>>
>>>>> In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
>>>>> I think that the spontaneously flag setting, will cause problems for other vendors too.
>>>>>
>>>>> Path Attribute - AS_PATH: empty
>>>>> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
>>>>> 0... .... = Optional: Not set
>>>>> .1.. .... = Transitive: Set
>>>>> ..0. .... = Partial: Not set
>>>>> ...1 .... = Extended-Length: Set
>>>>> .... 0000 = Unused: 0x0
>>>>> Type Code: AS_PATH (2)
>>>>> Length: 0
>>>>>
>>>>>
>>>>> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>>>>>
>>>>>> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
>>>>>> issue and more unfortunately I got my hands on devices I cannot use :-)
>>>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> foundry-nsp mailing list
>>> foundry-nsp@puck.nether.net
>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

I did wanted to turn the AS4 capability off but there is no option on the Mikrotik side. And from the CER side I did tried without luck.

> On 30 Jun 2023, at 11:59, Jörg Kost <jk@ip-clear.de> wrote:
>
> Yes, that also works without any problems, otherwise we would all have issues with our devices for years ;-) - please point out the extended-length. As a workaround, have you turned off as4 capability only for the neighbor Mikrotik router from CER configuration? Would be worth an idea. The problem doesn't seem to be related to AS4 Capability causally, but maybe this changes the flagging of the attribute on Mikrotik router.
>
> On 30 Jun 2023, at 10:52, Bogdan Rotariu wrote:
>
>> Just received a reponse from the Mikrotik ticket:
>>
>> "RFC 6793 updates RFC4271 where Section 4.1 states
>> "
>> A BGP speaker that advertises such a capability to a particular peer,
>> and receives from that peer the advertisement of such a capability,
>> MUST encode AS numbers as four-octet entities in both the AS_PATH
>> attribute and the AGGREGATOR attribute in the updates it sends to the
>> peer and MUST assume that these attributes in the updates received
>> from the peer encode AS numbers as four-octet entities.
>> "
>>
>> AS4_AGGREGATOR does not apply here in this case because both speakers are considered "NEW BGP Speakers"
>>
>> Section 3 states what is "NEW Speaker" and what is "OLD Speaker”
>>
>> "
>>
>>> On 30 Jun 2023, at 10:44, Jörg Kost <jk@ip-clear.de> wrote:
>>>
>>> I see, however, you won't be able to solve it any other way than
>>>
>>> 1.) Open a new bug report with extended-length at Mikrotik (or use older firmware?)
>>> or
>>> 2.) Use a route reflector, which takes the communication between the routers.
>>>
>>> There's no point in flagging if the length, for example, can be represented as fixed with 8 bits, or is even set to 0. So there is conflicting information in the BGP message and therefore an Attributes Length or Attributed Data error is thrown. Or do I miss something?
>>>
>>> IMHO, the Brocade/Extreme Device protects you from reading "out-of-bounds" and implements the RFC correctly. Otherwise these would be classic exploitable buffer overflow conditions.
>>>
>>> https://datatracker.ietf.org/doc/html/rfc1771 used to be much more striking: "Extended Length may be used only if the length of the attribute
>>> value is greater than 255 octets."
>>>
>>> While https://www.rfc-editor.org/rfc/rfc4271.html says:
>>> If the Extended Length bit of the Attribute Flags octet is set
>>> to 1, the third and fourth octets of the path attribute contain
>>> the length of the attribute data in octets.
>>>
>>>
>>>
>>> On 30 Jun 2023, at 0:41, Bogdan Rotariu wrote:
>>>
>>>> Ok, I can totally replicate the issue using Mikrotik's CHR latest 7.11beta2. Session between a CHR and a CER2024 closes with same error "Error: Invalid AGGREGATOR attribute length 8”. If anyone would like to do a test I would appreciate that.
>>>>
>>>>> On 30 Jun 2023, at 00:50, Bogdan Rotariu <bogdan@rotariu.ro> wrote:
>>>>>
>>>>> Ty, during my research I have found out that Mikrotik forces atomic-aggregate attribute to any announced prefixes, I guess the extended-length: set comes from that? This bug they acknowledge but said it has nothing to do with my issue and its just Brocade fault.
>>>>>
>>>>>> On 30 Jun 2023, at 00:27, Jörg Kost <jk@ip-clear.de> wrote:
>>>>>>
>>>>>> Bottom line: Vote with your wallet, buy some Extreme ;-)
>>>>>>
>>>>>> In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
>>>>>> I think that the spontaneously flag setting, will cause problems for other vendors too.
>>>>>>
>>>>>> Path Attribute - AS_PATH: empty
>>>>>> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
>>>>>> 0... .... = Optional: Not set
>>>>>> .1.. .... = Transitive: Set
>>>>>> ..0. .... = Partial: Not set
>>>>>> ...1 .... = Extended-Length: Set
>>>>>> .... 0000 = Unused: 0x0
>>>>>> Type Code: AS_PATH (2)
>>>>>> Length: 0
>>>>>>
>>>>>>
>>>>>> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>>>>>>
>>>>>>> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
>>>>>>> issue and more unfortunately I got my hands on devices I cannot use :-)
>>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> foundry-nsp mailing list
>>>> foundry-nsp@puck.nether.net
>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp


_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

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.

--
Bogdan-Stefan Rotariu
bogdan@rotariu.ro




> On 30 Jun 2023, at 11:59, Jörg Kost <jk@ip-clear.de> wrote:
>
> Yes, that also works without any problems, otherwise we would all have issues with our devices for years ;-) - please point out the extended-length. As a workaround, have you turned off as4 capability only for the neighbor Mikrotik router from CER configuration? Would be worth an idea. The problem doesn't seem to be related to AS4 Capability causally, but maybe this changes the flagging of the attribute on Mikrotik router.
>
> On 30 Jun 2023, at 10:52, Bogdan Rotariu wrote:
>
>> Just received a reponse from the Mikrotik ticket:
>>
>> "RFC 6793 updates RFC4271 where Section 4.1 states
>> "
>> A BGP speaker that advertises such a capability to a particular peer,
>> and receives from that peer the advertisement of such a capability,
>> MUST encode AS numbers as four-octet entities in both the AS_PATH
>> attribute and the AGGREGATOR attribute in the updates it sends to the
>> peer and MUST assume that these attributes in the updates received
>> from the peer encode AS numbers as four-octet entities.
>> "
>>
>> AS4_AGGREGATOR does not apply here in this case because both speakers are considered "NEW BGP Speakers"
>>
>> Section 3 states what is "NEW Speaker" and what is "OLD Speaker”
>>
>> "
>>
>>> On 30 Jun 2023, at 10:44, Jörg Kost <jk@ip-clear.de> wrote:
>>>
>>> I see, however, you won't be able to solve it any other way than
>>>
>>> 1.) Open a new bug report with extended-length at Mikrotik (or use older firmware?)
>>> or
>>> 2.) Use a route reflector, which takes the communication between the routers.
>>>
>>> There's no point in flagging if the length, for example, can be represented as fixed with 8 bits, or is even set to 0. So there is conflicting information in the BGP message and therefore an Attributes Length or Attributed Data error is thrown. Or do I miss something?
>>>
>>> IMHO, the Brocade/Extreme Device protects you from reading "out-of-bounds" and implements the RFC correctly. Otherwise these would be classic exploitable buffer overflow conditions.
>>>
>>> https://datatracker.ietf.org/doc/html/rfc1771 used to be much more striking: "Extended Length may be used only if the length of the attribute
>>> value is greater than 255 octets."
>>>
>>> While https://www.rfc-editor.org/rfc/rfc4271.html says:
>>> If the Extended Length bit of the Attribute Flags octet is set
>>> to 1, the third and fourth octets of the path attribute contain
>>> the length of the attribute data in octets.
>>>
>>>
>>>
>>> On 30 Jun 2023, at 0:41, Bogdan Rotariu wrote:
>>>
>>>> Ok, I can totally replicate the issue using Mikrotik's CHR latest 7.11beta2. Session between a CHR and a CER2024 closes with same error "Error: Invalid AGGREGATOR attribute length 8”. If anyone would like to do a test I would appreciate that.
>>>>
>>>>> On 30 Jun 2023, at 00:50, Bogdan Rotariu <bogdan@rotariu.ro> wrote:
>>>>>
>>>>> Ty, during my research I have found out that Mikrotik forces atomic-aggregate attribute to any announced prefixes, I guess the extended-length: set comes from that? This bug they acknowledge but said it has nothing to do with my issue and its just Brocade fault.
>>>>>
>>>>>> On 30 Jun 2023, at 00:27, Jörg Kost <jk@ip-clear.de> wrote:
>>>>>>
>>>>>> Bottom line: Vote with your wallet, buy some Extreme ;-)
>>>>>>
>>>>>> In your dump e.g. there is an empty AS-Path with length 0 and then Extended-Length is set anyway.
>>>>>> I think that the spontaneously flag setting, will cause problems for other vendors too.
>>>>>>
>>>>>> Path Attribute - AS_PATH: empty
>>>>>> Flags: 0x50, Transitive, Extended-Length, Well-known, Complete
>>>>>> 0... .... = Optional: Not set
>>>>>> .1.. .... = Transitive: Set
>>>>>> ..0. .... = Partial: Not set
>>>>>> ...1 .... = Extended-Length: Set
>>>>>> .... 0000 = Unused: 0x0
>>>>>> Type Code: AS_PATH (2)
>>>>>> Length: 0
>>>>>>
>>>>>>
>>>>>> On 29 Jun 2023, at 23:13, Bogdan Rotariu wrote:
>>>>>>
>>>>>>> Yes Netiron is a real stable software, we have plenty Brocades in use and except the ones that got many sessions and occasionally have memory issues, we never had any issues. Unfortunately I cannot convince Mikrotik that they have a bug and till now I cannot see anyone else on the forum or on their discord server that are affected by this
>>>>>>> issue and more unfortunately I got my hands on devices I cannot use :-)
>>>>>>>
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> foundry-nsp mailing list
>>>> foundry-nsp@puck.nether.net
>>>> http://puck.nether.net/mailman/listinfo/foundry-nsp

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@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

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@puck.nether.net> On Behalf Of J?rg Kost
Sent: Saturday, July 1, 2023 12:09 AM
To: Bogdan-Stefan Rotariu <bogdan@rotariu.ro>
Cc: foundry-nsp@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@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp

_______________________________________________
foundry-nsp mailing list
foundry-nsp@puck.nether.net
http://puck.nether.net/mailman/listinfo/foundry-nsp