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 [email protected] > On 30 Jun 2023, at 11:59, Jörg Kost <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>>> [email protected] >>>> http://puck.nether.net/mailman/listinfo/foundry-nsp
_______________________________________________ foundry-nsp mailing list [email protected] http://puck.nether.net/mailman/listinfo/foundry-nsp
