Posted on November 28, 2018 2:33 am
 |  Asked by Bryan Holloway
 |  59 views
0
0
Print Friendly, PDF & Email

We have a peering BGP session that keeps dropping. This is between two IPv6 peers. OPEN happens, capabilities are agreed open, and prefixes are exchanged via UPDATE messages.

Then one of the peers sends an UPDATE with ORIGIN, AS_PATH, and MP_UNREACH_NLRI attributes, which should be a valid update, much like ORIGIN, AS_PATH, and MP_REACH_NLRI. However, the Arista complains about a missing well-known attribute, and the data field is set to “3”, which indicates that it’s apparently wanting to see NEXTHOP(3). Consequently we send them a NOTIFICATION and the session drops.

Looking at the RFCs, this seems like a valid update to me (ORIGIN, AS_PATH, MP_UNREACH_NLRI). Is this perhaps a bug? Or am I missing something silly?

This is a DCS-7280SRA-48C6-M-F running 4.19.9M.

0
Posted by Kamlesh Sharma
Answered on November 28, 2018 6:24 am

Hi Bryan,

Yes, You are right. Based on the RFC we would just need the address family and the prefix details to be withdrawn. We have fixed this issue in our latest code 4.21 release.

Thanks
Kamlesh

Post your Answer

You must be logged in to post an answer.