Summary

  • Graceful Restart lets a peer retain routes temporarily, but that helper behavior depends on forwarding state remaining viable for the relevant address family.
  • A stale route, a restored session or an End-of-RIB marker does not prove next-hop resolution, FIB or label state, line-card continuity or packet delivery.
  • A continuity claim needs a joined, expiring receipt covering negotiated capability, flags, timers, retained routes, forwarding readback and measured traffic.

The quiet control plane and the blackholed packets

Imagine a control-plane restart. The peer keeps the routes, marks them stale and avoids a withdrawal storm. The BGP session returns inside Restart Time and an End-of-RIB marker arrives. From the route table, the event looks graceful. Yet probes fail because the restarting system did not preserve the forwarding entry that those routes still assumed.

That sequence is not a defect in the idea of Graceful Restart. It is a scope error in the assurance. Retained routing information tells a helper what it may continue to believe temporarily. It does not observe the line card, next-hop adjacency, label binding or packet path on the restarting node.

The capability is conditional and address-family specific

RFC 4724 defines a capability, Restart Time and per-AFI/SAFI flags. A speaker may claim forwarding preservation for an address family; it can also advertise the capability without such tuples merely to support End-of-RIB behavior or help a restarting peer. “GR capable” therefore is not one universal forwarding claim.

During restart, the speaker retains forwarding state if possible and marks it stale. The Forwarding State bit should indicate that state was actually preserved. The receiver retains eligible routes, marks them stale and removes them if the session misses Restart Time. After reconnection, an absent forwarding-state indication for an address family requires immediate removal of its retained stale routes.

The timers bound belief; they do not validate it. End-of-RIB says the initial update stream is complete and causes unreplaced stale routes to be removed. It does not say packets crossed the data plane during the interval.

Error recovery and maintenance are different cases

RFC 8538 extends GR to selected NOTIFICATION-triggered resets only when the relevant capability is exchanged, and makes the stale timer mandatory. The reset cause, negotiated N bit and error class belong in the evidence. A generic “session restarted” entry is too weak.

RFC 6198 draws a sharper boundary for maintenance: Graceful Restart applies when forwarding is preserved through a control-plane restart. If the work interrupts a link, line card or forwarding resource, graceful shutdown—not stale-route retention—is the relevant mechanism. Retaining reachability for a resource that is intentionally leaving service can prolong loss rather than hide harmless control-plane churn.

Sources