On 2/19/2019 3:19 PM, Bjørn Mork wrote:
Brian Rak <[email protected]> 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 [email protected]
https://puck.nether.net/mailman/listinfo/juniper-nsp
