Border Gateway Protocol 4 (BGP-4) Send Hold Timer
updates
- rfc-4271 — A Border Gateway Protocol 4 (BGP-4)
Extracted elements (18)
A BGP speaker in the Established state may encounter a peer advertising a TCP Receive Window of zero, preventing transmission of KEEPALIVE, UPDATE, or any other BGP messages. Existing BGP implementations have no visibility into TCP window state and no mechanism to detect or handle this condition consistently, leading to stale routing information and potential traffic loss.
BGP speakers following this specification do not rely exclusively on remote systems closing blocked connections; they also locally close blocked connections. This addresses the asymmetry where a local system can detect the blockage but the remote system (if overwhelmed) may never initiate closure.
Failure to terminate a blocked BGP connection can cause the affected speaker to operate with outdated routing information, negatively impacting convergence for an entire autonomous system or group of autonomous systems. This phenomenon is believed to have contributed to IP traffic packet loss events in the global Internet routing system (described as 'BGP zombies').
When SendHoldTimer_Expires occurs, the local system will likely be unable to deliver a NOTIFICATION message to the remote peer since the connection is blocked. The specification allows an optional attempt to send NOTIFICATION only if doing so will not delay connection teardown, acknowledging the asymmetric visibility between local and remote systems.
BGP speakers SHOULD provide the reason 'Send Hold Timer Expired' as part of their operational state, for example as bgpPeerLastError in the BGP MIB (RFC 4273), to assist operators in diagnosing connection closures.
If SendHoldTime is non-zero, it MUST be greater than the value of HoldTime.
Implementations MAY make the value of SendHoldTime configurable, either globally or on a per-peer basis, within the constraints that SendHoldTime must be greater than HoldTime when non-zero.
It is RECOMMENDED that implementations enable SendHoldTimer by default without requiring additional configuration, given that operators may be unfamiliar with this fault detection mechanism.
The default value of SendHoldTime for a BGP connection SHOULD be the greater of 8 minutes or 2 times the negotiated HoldTime.
When the SendHoldTimer expires, an error MUST be logged in the local system indicating the 'Send Hold Timer Expired' Error Code.
When the SendHoldTimer_Expires event occurs, the BGP connection MUST be closed. A NOTIFICATION message with the 'Send Hold Timer Expired' Error Code MAY be sent if doing so will not delay closing the connection.
SendHoldTimer is a new optional BGP FSM session attribute (attribute 14) that tracks how long a speaker may remain in the Established state without successfully sending any BGP message to its peer. SendHoldTime (attribute 15) stores the configured initial value for this timer and may be set independently per peer.
The NOTIFICATION message for 'Send Hold Timer Expired' uses BGP Error Code 8 and subcode 0. The subcode field is not used and no additional data is appended to the end of the NOTIFICATION message.
IANA has registered value 8 for 'Send Hold Timer Expired' in the 'BGP Error (Notification) Codes' registry within the 'Border Gateway Protocol (BGP) Parameters' registry group.
This specification does not change BGP's security characteristics. Implementing the BGP SendHoldTimer enhances network resilience by terminating connections with malfunctioning or overwhelmed remote peers, reducing the risk of stale routing information propagation.
A new FSM event, Event 29 (SendHoldTimer_Expires), is defined as an optional event generated when the SendHoldTimer expires. Upon this event in the Established state, the local system optionally sends a NOTIFICATION, logs an error, releases all BGP resources, sets ConnectRetryTimer to zero, drops the TCP connection, increments ConnectRetryCounter, optionally damps peer oscillations, and transitions to Idle.
Each time the local system sends a BGP message in the Established state, it restarts the SendHoldTimer unless SendHoldTime is zero or the negotiated HoldTime is zero (in which case SendHoldTimer is stopped). The SendHoldTimer is also stopped following any transition out of Established state as part of releasing BGP resources.
In the OpenConfirm state, upon receiving a KEEPALIVE (Event 26), the FSM now additionally starts the SendHoldTimer if SendHoldTime is non-zero before transitioning to the Established state. This extends the existing RFC 4271 behavior of restarting HoldTimer and changing state.