[f-nsp] Netiron AS4 capabilities

[Jörg Kost]

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