so interested in responses to this.
No snark intended here, but unclear what sort of response you would be looking for. RFC4271 : Sec 6, Error Handling
When any of the conditions described here are detected, a NOTIFICATION message, with the indicated Error Code, Error Subcode, and Data fields, is sent, and the BGP connection is closed (unless it is explicitly stated that no NOTIFICATION message is to be sent and the BGP connection is not to be closed). If no Error Subcode is specified, then a zero MUST be used.
Section 6.3 , Update Message Error Handling All errors detected while processing the UPDATE message MUST be
indicated by sending the NOTIFICATION message with the Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error.
A standard BGP implementation that detects an error MUST close the session per the spec. This was updated by RFC7606, Revised Error Handling for BGP, which provides for alternative ways to handle these errors, depending on what they are. Not all require a session reset. https://datatracker.ietf.org/doc/html/rfc7606 If your vendor's BGP implementation isn't RFC7606 compliant, then it's likely in your best interests to ask them to support it. The possibility of receiving a malformed update is omnipresent, and 7606 support can dramatically reduce the impact of such things when they do occur. On Tue, May 20, 2025 at 12:28 PM Chris Costa via NANOG < nanog@lists.nanog.org> wrote:
Did see an impact on some 7280R3 switches running EOS 4.29.7, so interested in responses to this.
On Tue, May 20, 2025 at 7:32 AM Ryan Rawdon via NANOG < nanog@lists.nanog.org> wrote:
On 2025-05-20 09:48, John Stitt wrote:
For what it's worth, while we didn't see sessions reset, I do recall that we have bgp-error-tolerance enabled on our Juniper routers, so it's possible that kept our sessions from resetting.
Customer that saw sessions drop is running Arista.
John Stitt
Arista appears to have made changes for bug 899981 to drop (at least) certain malformed attributes. Was anyone running EOS versions greater than the following, and had Arista EOS reset the sessions today? We are unsure whether the change made in these versions would have provided a cleaner response to today's malformed attribute.
4.28.11+
4.29.8+
4.30.6+
4.31.2+ _______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/FXGV24EY...
_______________________________________________ NANOG mailing list
https://lists.nanog.org/archives/list/nanog@lists.nanog.org/message/KXFOVLDN...