Or do the sensible thing and just drop the announcement and log the problem.
Which is exactly what an RFC7606 compliant device will do for an unknown path attribute. https://www.rfc-editor.org/rfc/rfc7606#page-5 o Treat-as-withdraw: In this approach, the UPDATE message containing the path attribute in question MUST be treated as though all contained routes had been withdrawn just as if they had been listed in the WITHDRAWN ROUTES field (or in the MP_UNREACH_NLRI attribute if appropriate) of the UPDATE message, thus causing them to be removed from the Adj-RIB-In according to the procedures of [RFC4271 <https://www.rfc-editor.org/rfc/rfc4271>]. d. If any of the well-known mandatory attributes are not present in an UPDATE message, then "treat-as-withdraw" MUST be used. (Note that [RFC4760] reclassifies NEXT_HOP as what is effectively discretionary.) e. "Treat-as-withdraw" MUST be used for the cases that specify a session reset and involve any of the attributes ORIGIN, AS_PATH, NEXT_HOP, MULTI_EXIT_DISC, or LOCAL_PREF. On Wed, Aug 30, 2023 at 10:01 AM Eugeniu Patrascu <eugen@imacandi.net> wrote:
On Wed, Aug 30, 2023 at 4:04 PM William Herrin <bill@herrin.us> wrote:
On Wed, Aug 30, 2023 at 4:50 AM Mike Lyon <mike.lyon@gmail.com> wrote:
Ran across this article today and haven't seen posts about it so i figured I would share:
https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling
Can you imagine, as the origin of a route, troubleshooting a connectivity issue in which Internet BGP routers far from your control have trouble with attributes attached by their peers and then "did their best" with your route instead of dropping the session and essentially demanding intervention by the network operator?
Dumping the session may seem extreme, but there's a good reason for it.
Or do the sensible thing and just drop the announcement and log the problem. This might be a problem in a DFZ environment, but albeit a small one. Or, drop the invalid attribute and treat the announcement as a regular one.