Mailing List Archive: JunOS interop problems with RFC5549

JunOS interop problems with RFC5549

Feb 19, 2019, 11:53 AM

Post #1 of 5 (1013 views)

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

It seems like JunOS does not fully respect the RFC here, and only
accepts 16 byte next hops.

Has anyone else run into this?

_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: JunOS interop problems with RFC5549 [ In reply to ]

bjorn at mork

Feb 19, 2019, 12:19 PM

Post #2 of 5 (1013 views)

Permalink

Brian Rak <brak@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
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: JunOS interop problems with RFC5549 [ In reply to ]

brak at gameservers

Feb 19, 2019, 12:22 PM

Post #3 of 5 (1013 views)

Permalink

On 2/19/2019 3:19 PM, Bjørn Mork wrote:
> Brian Rak <brak@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)
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: JunOS interop problems with RFC5549 [ In reply to ]

bjorn at mork

Feb 19, 2019, 1:08 PM

Post #4 of 5 (1013 views)

Permalink

Brian Rak <brak@gameservers.com> writes:

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

Ah, right. And the RFC2545 requirements are also fulfilled?:

The link-local address shall be included in the Next Hop field if and
only if the BGP speaker shares a common subnet with the entity
identified by the global IPv6 address carried in the Network Address
of Next Hop field and the peer the route is being advertised to.

In all other cases a BGP speaker shall advertise to its peer in the
Network Address field only the global IPv6 address of the next hop
(the value of the Length of Network Address of Next Hop field shall
be set to 16).

Bjørn
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp

Re: JunOS interop problems with RFC5549 [ In reply to ]

brak at gameservers

Feb 19, 2019, 1:35 PM

Post #5 of 5 (1013 views)

Permalink

On 2/19/2019 4:08 PM, Bjørn Mork wrote:
> Brian Rak <brak@gameservers.com> writes:
>
>> 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)
> Ah, right. And the RFC2545 requirements are also fulfilled?:
>
> The link-local address shall be included in the Next Hop field if and
> only if the BGP speaker shares a common subnet with the entity
> identified by the global IPv6 address carried in the Network Address
> of Next Hop field and the peer the route is being advertised to.
>
> In all other cases a BGP speaker shall advertise to its peer in the
> Network Address field only the global IPv6 address of the next hop
> (the value of the Length of Network Address of Next Hop field shall
> be set to 16).
>
>
>
> Bjørn
In this case, they're peering over an IPv6 link-local address. The next
hop field contains the link local address repeated twice. The RFC is
not particularly clear on what to do if there's no global address available.
_______________________________________________
juniper-nsp mailing list juniper-nsp@puck.nether.net
https://puck.nether.net/mailman/listinfo/juniper-nsp