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