Summary

  • RFC 1267 made a peer’s routing table memory part of one live BGP connection: speakers exchanged a complete initial table, sent increments thereafter and retained the current peer table for that connection’s duration.
  • RFC 4271 made connection close an implicit withdrawal boundary; RFC 4724 then allowed a negotiated exception in which selected address-family routes could survive temporarily as stale state until replacement, End-of-RIB or expiry.
  • RFC 8538 added an explicit Hard Reset boundary for failures that should not receive graceful treatment, while RFC 9494 extended stale memory only with stronger labels, lower preference, propagation limits and affirmative per-family configuration.

The first table was the shared beginning

RFC 1267 described BGP-3 as a conversation with a memory. Once two speakers had established their transport connection and exchanged the opening messages, the initial data flow carried the entire BGP routing table. After that, UPDATE messages carried only incremental changes.

The economy is obvious: do not resend an unchanged table merely to prove that it still exists. But the saving moves a requirement from the wire into state. Each speaker had to retain the current version of every peer’s routing table for the duration of the connection. An increment had meaning only against the complete state that preceded it.

That wording placed a clean boundary around the memory. It belonged to a particular peer connection. KEEPALIVE messages tested whether that connection remained live. An error produced a NOTIFICATION and a close; the finite-state machine released connection resources and moved back toward a state from which another session could be attempted.

Nothing in that receipt made the retained table a permanent assertion about identity, authority or the physical world. It was protocol input learned from one peer while a defined conversation remained in force. A live TCP session did not prove every route correct. A retained entry did not prove that forwarding matched it. The shared history made incremental processing possible; it did not certify packet delivery.

Close became an implicit withdrawal

RFC 4271 sharpened the bookkeeping. It separated Adj-RIBs-In, the routes learned from peers; the Loc-RIB, the routes selected for local use; and Adj-RIBs-Out, the routes prepared for advertisement. The three records can influence one another without becoming the same record.

It also named three ways a route could leave service. A peer could explicitly withdraw NLRI. It could advertise a replacement. Or the BGP connection could close, implicitly removing all routes that the two speakers had advertised to one another.

The error path follows that boundary. Closing the connection clears the associated Adj-RIB-In, invalidates local selections that depended on the peer, reruns route selection and causes withdrawals or replacements to be advertised as necessary. This is an evidence rule, not a claim that a physical neighbour ceased to exist at the same instant. The base protocol says the peer-specific control-plane input is no longer current enough to remain in service.

That distinction matters because forwarding hardware may still contain an entry after the control channel fails. The existence of that entry answers a different question. Under the ordinary rule, old peer input cannot silently acquire a new life merely because a device has not yet erased every consequence of it.

Graceful Restart made survival conditional

RFC 4724 introduced a deliberate exception for a restarting BGP control plane that might preserve forwarding. The exception begins with negotiation. The Graceful Restart Capability carries restart information and address-family scope; per-AFI/SAFI forwarding-state information says what a restarting speaker claims it preserved. Capability support, a restart indication and a forwarding-state indication are separate facts.

A receiving speaker may retain the restarting peer’s routes only for the negotiated address families. It marks those routes stale. The label is the central honesty mechanism: the route remains usable under the extension, but the fresh session has not yet re-established it.

The permission has several exits. If the session is not re-established within Restart Time, the stale routes must be deleted. If the new exchange does not affirm forwarding state for the family, omits the family or omits the capability, retention ends immediately. Fresh UPDATEs replace matching stale entries.

Then End-of-RIB closes the replacement window. For an address family with no routes, it can be an empty UPDATE; emptiness is valuable because it says the initial update has finished rather than merely fallen silent. Once End-of-RIB arrives, any route for that family that remains stale is removed.

The sequence therefore yields a bounded ledger: old route retained, uncertainty marked, new session established, new routes replace old entries, completion explicitly recorded, unmatched memory flushed. It does not yield a recovery receipt. RFC 4724 warns that transient loops or blackholes can occur, and that graceful BGP behaviour offers less benefit when the IGP and BGP restart together without compatible continuity beneath them.

An error could be graceful, but not by accident

The original graceful-restart design did not treat every NOTIFICATION exchange as a reason to retain routes. RFC 8538 added a negotiated N bit so peers could apply graceful semantics after receiving a NOTIFICATION or after Hold Time expiry when both sides had agreed to that behaviour.

It also supplied the inverse signal: a Cease/Hard Reset subcode asks for the base full reset. The distinction prevents “graceful” from becoming an invisible default for every failure. One record explains the observed protocol condition; another records the decision that prior state must not survive it. Hard Reset does not diagnose the root cause, but it makes the memory boundary explicit.

RFC 8538 requires a configurable timer for stale routes, suggests 180 seconds and says infinite retention must not be the default. The exact operational choice still belongs to an operator and implementation. The standard’s deeper point is that a retained uncertainty needs an expiry, especially when repeated resets could otherwise keep refreshing a state that never becomes current again.

Longer-lived memory carried a larger warning label

RFC 9494’s Long-Lived Graceful Restart extends retention beyond ordinary Restart Time. It does not erase the exception’s identity. Helpers attach the transitive LLGR_STALE community; routes marked NO_LLGR are excluded; long-lived stale routes are made least preferred; and they normally are not propagated to peers that did not negotiate LLGR.

Long-Lived Stale Time is scoped per AFI/SAFI and can be shortened locally. Enabling LLGR requires affirmative configuration for each family and must not be the default. Those controls recognize that more time is not neutral. A stale route that persists for conventional reachability can cause loss of connectivity, even when its label and preference correctly describe its status.

Least preferred is not the same as harmless. Propagation-limited is not the same as contained in forwarding. A capability says two implementations understand the mechanism; it does not prove that the next hop still works, that policy still authorizes the path or that a user’s packets arrive.

Sources