When BGP Graceful Restart Wasn't Graceful#

Marian Rychtecky – NIX.CZ

• Why: The kind of hard-won postmortem NANOG exists for: a GR feature that lengthened an outage from "hidden" to two minutes, with packet captures, lab reproduction, and multiple vendor bugs unpacked.
• What: During a firewall HA upgrade, BGP sessions re-established but carried zero prefixes for ~121s. Root causes found: (1) the router sent TCP RST on the new connection because the old session wasn't cleanly torn down — violating RFC 4724's "treat old session as terminated"; (2) the firewall's GR coupled IPv4 and IPv6, so IPv4 routes waited on a stuck IPv6 session's End-of-RIB (the suspicious ~120s was the default reconnect timer); (3) a parsing bug stored the IPv6 peer as 2001:db8:1: (missing ::2), so the OS couldn't find the VRF context and RST'd. Vendor fix lands in 8.0.1 (Aug 2026), not backported to supported 7.4/7.6 branches; workaround: set connect-timer 1.
• How: Classic disciplined troubleshooting: EoR timing analysis, packet captures on both sides, a BIRD lab where impolite kills (kill -9) reproduced the RST window, two separate vendor tickets, and the operational mitigations (short connect timer, static routes with AD 255 during upgrades).
• Where applicable: Anyone running BGP GR across dual-stack, multi-vendor HA pairs — the failure pattern (AFI-coupled GR state, TCP session cleanup on failover) is general even though the specific bugs are vendor-embedded.