It's probably not a secret that this recurred last evening between roughly 20:34 and 23:02 GMT -5/Central. With the offending prefix [per my logs] being 2a0c:b641:309::/48. Looks like I'll finally be contacting my var today [Juniper] to see specifically which versions will address this issue, but I'd also like to ask, based on this discussion from the first go around [I'm not in the correct circles to see any recent discussion] https://social.bgp.tools/@bgptools/statuses/01K7072TB9HS4JYN8E5Z01GEPK "The main cause of disruption peoples IX route server sessions going down (see image of MegaIXs looking glass), if IX's were running a modern version of bird/OpenBGPd this would have been filtered out!" Is there something "more" that could be done with bird on the IX to prevent future unknown unknowns from causing similar issues? -Michael
-----Original Message----- From: Michael Hare via mice-discuss <mice-discuss@lists.micemn.net> Sent: Tuesday, October 7, 2025 4:28 PM To: Chris Wopat <wopat@wiscnet.net>; mice-discuss@lists.micemn.net Subject: RE: v6 on rs1/rs2 fubar?
I am late to the game.
Me too, starting 14:49 Central/GMT-5 for us. Yes I'm a Juniper.
= Yes, we use BFD. = Yes, we have bgp-error-tolerance enabled. "set protocols bgp bgp-error-tolerance" [yes, my session is in global] = No, I haven't contacted Juniper, but I seem to have a misunderstanding about "bgp-error-tolerance" at the very least.
Oct 7 14:49:10 r-minneapolis-511.uwsys.net [LEVEL='daemon.warning'] rpd[32044]: %DAEMON-4-RPD_BGP_NEIGHBOR_STATE_CHANGED: BGP peer 2001:504:27::d1af:0:1 (External AS 53679) changed st ate from Established to Idle (event RecvUpdate) (instance master) Oct 7 14:49:10 r-minneapolis-511.uwsys.net [LEVEL='daemon.err'] rpd[32044]: %DAEMON-3: BGP ERROR: Insufficient data for the packet Oct 7 14:49:10 r-minneapolis-511.uwsys.net [LEVEL='daemon.warning'] rpd[32044]: %DAEMON-4: bgp_read_v4_update:13800: NOTIFICATION sent to 2001:504:27::d1af:0:1 (External AS 53679): co de 3 (Update Message Error) subcode 1 (invalid attribute list) Oct 7 14:49:10 r-minneapolis-511.uwsys.net [LEVEL='daemon.err'] rpd[32044]: %DAEMON-3: Received malformed update from 2001:504:27::d1af:0:1 (External AS 53679) Oct 7 14:49:10 r-minneapolis-511.uwsys.net [LEVEL='daemon.err'] rpd[32044]: %DAEMON-3: Family inet6-unicast, prefix 2402:2de0::/32 Oct 7 14:49:10 r-minneapolis-511.uwsys.net [LEVEL='daemon.err'] rpd[32044]: %DAEMON-3: Malformed Attribute Unknown(35) flag 0xe0 length 1024. Oct 7 14:49:10 r-minneapolis-511.uwsys.net [LEVEL='daemon.err'] rpd[32044]: %DAEMON-3: BGP ERROR: Insufficient data for the packet
-Michael
-----Original Message----- From: Chris Wopat <wopat@wiscnet.net> Sent: Tuesday, October 7, 2025 4:10 PM To: mice-discuss@lists.micemn.net Subject: Re: v6 on rs1/rs2 fubar?
A few years ago this came out:
https://urldefense.com/v3/__https://blog.benjojo.co.uk/post/bgp-path- attributes-grave-error-
handling__;!!Mak6IKo!MP3CJWT3VXc9yyZOF25Zkl6ylazMccDKnoNw_w6IpTdMY
ZVmAbEhYBGcObRfkZtQ-jEoiojfbC9uW1cwqw$
And the Juniper specific link is to enable bgp-error-tolerance:
https://urldefense.com/v3/__https://supportportal.juniper.net/s/article/2023... 08-29-Out-of-Cycle-Security-Bulletin-Junos-OS-and-Junos-OS-Evolved-A- crafted- BGP-UPDATE-message-allows-a-remote-attacker-to-de-peer-reset-BGP- sessions-CVE-2023-
4481__;!!Mak6IKo!MP3CJWT3VXc9yyZOF25Zkl6ylazMccDKnoNw_w6IpTdMYZV
mAbEhYBGcObRfkZtQ-jEoiojfbC8RD26zjg$
https://urldefense.com/v3/__https://www.juniper.net/documentation/us/en/soft
ware/junos/bgp/topics/topic-map/bgp-error-
messages.html__;!!Mak6IKo!MP3CJWT3VXc9yyZOF25Zkl6ylazMccDKnoNw_w6I
pTdMYZVmAbEhYBGcObRfkZtQ-jEoiojfbC9K24DUbQ$
We (as2381) are not having resets and do have this enabled, as a point of comparison.
Cheers, -- Chris Wopat Network Engineer, WiscNet wopat@wiscnet.net 608-210-3965 _______________________________________________ mice-discuss mailing list -- mice-discuss@lists.micemn.net To unsubscribe send an email to mice-discuss-leave@lists.micemn.net
mice-discuss mailing list -- mice-discuss@lists.micemn.net To unsubscribe send an email to mice-discuss-leave@lists.micemn.net