Graceful Restart Mechanism for BGP
updated by
- rfc-8538 — Notification Message Support for BGP Graceful Restart
updates
- rfc-4271 — A Border Gateway Protocol 4 (BGP-4)
Extracted elements (29)
A speaker without forwarding state preservation capability is still recommended to advertise the Graceful Restart Capability (with no AFI/SAFI tuples) for two reasons: to signal its intention to generate End-of-RIB markers for convergence, and to indicate support for peers wishing to perform a graceful restart.
The End-of-RIB marker's usefulness extends beyond graceful restart: generating it upon completion of initial routing updates is generally recommended for routing convergence, regardless of whether the speaker supports forwarding state preservation.
The R (Restart State) bit in the Restart Flags is included to prevent deadlock when multiple BGP speakers peering with each other all restart simultaneously. Without it, each restarting speaker would wait indefinitely for End-of-RIB markers from peers that are themselves waiting.
To restrict graceful restart to planned restarts only (as opposed to all restarts including power failures), an implementation can set the Forwarding State bit to 1 after a planned restart and to 0 otherwise. This is presented as one approach; other mechanisms are out of scope.
Including <AFI=IPv4, SAFI=unicast> in the Graceful Restart Capability does not imply that IPv4 unicast routing information must use BGP multiprotocol extensions; it may still be carried in the NLRI field of a standard BGP UPDATE message.
When a sender of the Graceful Restart Capability includes no <AFI, SAFI> tuples, it indicates inability to preserve forwarding state but support for Receiving Speaker procedures. In that case the Restart Time value is irrelevant. This allows partial deployment where only receiving-side behavior is implemented.
When the Receiving Speaker detects the old TCP session has not terminated but receives a new open connection from a Graceful Restart-capable peer, it MUST treat the new connection as indication of the old session's termination, close the old session without sending a NOTIFICATION, and retain the new connection. This differs from default BGP-4 Section 6.8 behavior.
A BGP speaker MUST NOT include more than one instance of the Graceful Restart Capability in its capability advertisement. If more than one instance is carried, the receiver MUST ignore all but the last instance.
After route selection, the Restarting Speaker's forwarding state MUST be updated, previously stale information MUST be removed, and the End-of-RIB marker MUST be sent once initial update for each address family is complete.
If the session is not re-established within the Restart Time advertised by the peer, the Receiving Speaker MUST delete all stale routes from that peer.
Normal BGP procedures MUST be followed when the TCP session terminates due to sending or receiving a BGP NOTIFICATION message; graceful restart procedures do not apply in that case.
Once the session is re-established, if the Forwarding State bit for a specific AFI/SAFI is not set, if the AFI/SAFI is absent from the new Graceful Restart Capability, or if no Graceful Restart Capability is received at all, the Receiving Speaker MUST immediately remove all stale routes for that address family.
The End-of-RIB marker MUST be sent by a BGP speaker to its peer once it completes the initial routing update (including the case when there is no update to send) for an address family after the BGP session is established.
The Receiving Speaker MUST replace stale routes with routing updates received from the peer. Once the End-of-RIB marker for an address family is received, it MUST immediately remove any routes still marked stale for that address family.
The Restarting Speaker MUST defer route selection for an address family until it either receives the End-of-RIB marker from all eligible peers or the Selection_Deferral_Timer expires. An implementation MUST support a configurable Selection_Deferral_Timer to bound deferral time.
The Restarting Speaker MUST set the Restart State bit in the Graceful Restart Capability of its OPEN message when re-establishing sessions. The Forwarding State bit for an address family MUST only be set if forwarding state was actually preserved for that family during the restart (unless overridden by configuration).
When restarting, the Restarting Speaker MUST retain, if possible, forwarding state for BGP routes in the Loc-RIB and MUST mark them as stale. It MUST NOT differentiate between stale and other information during forwarding.
When the Receiving Speaker detects TCP session termination for a peer that advertised Graceful Restart Capability, it MUST retain routes from that peer for all address families listed in the capability and MUST mark them as stale. A previously stale route MUST be deleted to handle consecutive restarts. The router MUST NOT differentiate stale from other routing information during forwarding.
The End-of-RIB marker is an UPDATE message with no reachable NLRI and empty withdrawn NLRI, signaling completion of initial routing updates after session establishment. For IPv4 unicast it is a minimum-length UPDATE; for other address families it is an UPDATE containing only MP_UNREACH_NLRI with no withdrawn routes for that <AFI, SAFI>.
The Forwarding State (F) bit in the Flags for Address Family field indicates whether forwarding state for routes advertised with the given AFI/SAFI was preserved during the previous BGP restart. When set (value 1), forwarding state has been preserved.
The Graceful Restart Capability (capability code 64) is a BGP capability allowing a speaker to express its ability to preserve forwarding state during restart. Its value contains a 4-bit Restart Flags field, a 12-bit Restart Time field, and zero to 63 tuples of <AFI (16 bits), SAFI (8 bits), Flags for Address Family (8 bits)>.
The Restart State (R) bit in the Restart Flags field indicates that the BGP speaker has restarted. When set, the peer MUST NOT wait for the End-of-RIB marker from this speaker before advertising routing information to it, preventing deadlock among multiple simultaneously restarting speakers.
This document registers a new BGP capability: Graceful Restart Capability with Capability Code 64, assigned by IANA in the BGP Capability Codes registry.
Graceful restart allows a new TCP connection to replace an existing one, potentially enabling denial-of-service or route injection attacks if an attacker can impersonate a legitimate peer. However, the existing BGP-4 security model already relies on TCP MD5 authentication (BGP-AUTH) to protect against such threats, and this proposal does not change the underlying security model.
If an attacker successfully opens a TCP connection impersonating a legitimate peer, the attack window for route insertion is small: the legitimate peer will reconnect, terminating the attacker's connection, reducing the attack to a transient denial of service rather than a persistent route hijack.
In the Established state, when a new TCP connection arrives (Event 16 or 17) and the Graceful Restart Capability with one or more AFIs/SAFIs has been received, the local system retains routes per the Receiving Speaker procedures, releases all other BGP resources, drops the old TCP connection, initializes new BGP resources, resets ConnectRetryCounter to zero, starts ConnectRetryTimer, and transitions to Connect state.
In the Established state, when TcpConnectionFails (Event 18) occurs and Graceful Restart Capability with one or more AFIs/SAFIs has been received, the local system retains routes per Receiving Speaker procedures, releases all other BGP resources, drops the TCP connection, increments ConnectRetryCounter, and transitions to Idle (instead of deleting all routes as in the baseline FSM).
In the Idle state, BGP resource initialization is modified to exclude resources required to retain routes according to Receiving Speaker procedures, ensuring stale routes are preserved across reconnection attempts.
The Graceful Restart Capability value encodes: Restart Flags (4 bits, MSB is Restart State R bit), Restart Time in seconds (12 bits), followed by per-AFI tuples each containing AFI (16 bits), SAFI (8 bits), and Flags for Address Family (8 bits, MSB is Forwarding State F bit).