[j-nsp] JunOS interop problems with RFC5549

[Brian Rak]

On 2/19/2019 3:19 PM, Bjørn Mork wrote:
> Brian Rak <brak at gameservers.com> writes:
>
>> I'm running into an issue where JunOS will not accept BGP updates
>> containing a MP_REACH_NLRI attribute with a 32 byte nexthop.  As soon
>> as I send one, the session gets closed and the following logged:
>>
>> rpd[16187]: bgp_read_v4_update:12111: NOTIFICATION sent to
>> fe80::ae1f:6bff:fe8a:435d (External AS 64555): code 3 (Update Message
>> Error) subcode 9 (error with optional attribute)
>> rpd[16187]: Received malformed update from fe80::ae1f:6bff:fe8a:435d
>> (External AS 64555)
>> rpd[16187]:   Family inet-unicast, prefix 0.0.0.0/0
>> rpd[16187]:   Malformed Attribute MP_REACH(14) flag 0x80 length 42.
>>
>> The other end of the BGP session is a Cumulus router (or a linux
>> machine running FRR).  If I patch that end to only send 16 byte
>> nexthops, JunOS accepts the route and seems to work just fine.
>>
>> RFC5549 states:
>>
>>>     o  Length of Next Hop Address = 16 or 32
>>>    o  Next Hop Address = IPv6 address of next hop (potentially followed
>>        by the link-local IPv6 address of the next hop).  This field is to
>>        be constructed as per Section 3 of [RFC2545].
>
> and also:
>
>     A BGP speaker MUST only advertise to a BGP peer the IPv4 or VPN-IPv4
>     NLRI with an IPv6 Next Hop if the BGP speaker has first ascertained
>     via BGP Capability Advertisement that the BGP peer supports the
>     Extended Next Hop Encoding capability for the relevant AFI/SAFI pair.
>
>
> And I guess your Cumulus router failed to do this?
>
>
> Bjørn
They both negotiate the Extended next hop capability, and JunOS accepts 
the routes just fine if I make Cumulus only send 16 byte nexthops (still 
IPv6, just not containing a link-local address)