Day 49 — BGP Timers: Keepalive, Hold Time, ConnectRetry and SendHoldTimer

1. Opening

BGP's traditional liveness model is often summarized as 'keepalives every 60 seconds, dead after 180 seconds.' That shortcut is useful only until a production fault violates the assumptions behind it. The negotiated Hold Time, the local Keepalive interval, ConnectRetry behavior, and the newer SendHoldTimer solve different problems. Treating them as one knob can create unnecessary churn or hide one-way failures.

2. Concept and standards behavior

RFC 4271 defines the HoldTimer and KeepaliveTimer as part of the BGP finite-state machine. The negotiated Hold Time is the smaller non-zero value proposed by the peers; if the negotiated Hold Time is zero, periodic keepalives and hold expiry are disabled for that session. Cisco IOS XE commonly documents 60-second keepalive and 180-second hold defaults, but those are implementation defaults and must not be presented as universal RFC constants. RFC 9687, published in November 2024, updates the FSM with SendHoldTimer behavior so a local speaker can close a connection when it detects that the remote side is not processing sent BGP messages instead of relying indefinitely on the remote speaker to close it.

A recurring discipline in convergence engineering is to separate failure detection, control-plane reaction, RIB decision, and FIB repair. Different features accelerate different stages. A design that reports a fast protocol event but still forwards into a dead path has not achieved useful convergence.

3. Scenario success criteria

1. Define the failure signal before tuning convergence.
2. Capture control-plane and forwarding state before modification.
3. Change only one detection or HA mechanism at a time.
4. Use a positive traffic test and a negative/containment test.
5. Preserve logs and timing evidence through the fault.
6. Roll back if instability increases or forwarding safety becomes less certain.

4. Topology

BGP Timers: Keepalive, Hold Time, ConnectRetry and SendHoldTimer

                 +--------------------+
                 |   CORE / UNDERLAY   |
                 +----------+---------+
                            |
        +-------------------+-------------------+
        |                                       |
   EDGE-A / AS65010                        EDGE-B / AS65020
   Lo0 192.0.2.10                          Lo0 192.0.2.20
        |                                       |
        +----------- service / test ------------+
                     203.0.113.0/24

The exact node roles change by day; the matching SVG/PNG diagram is authoritative for the lab arrangement.

5. Prerequisites

• Cisco IOS XE 17.18.x documentation baseline unless the post explicitly calls out a broader 17.x feature document.
• Documentation-safe addressing and lab-only credentials.
• Stable IGP/underlay before enabling fast failure mechanisms.
• Time synchronization for event sequencing.
• Independent management access.
• Baseline captures of BGP summary, route detail, RIB/FIB state and traffic.

7. Verification before modification

show bgp ipv4 unicast summary
show bgp ipv4 unicast neighbors
show bgp ipv4 unicast 203.0.113.0/24
show ip route
show ip cef 203.0.113.1 detail
show logging

Where relevant, add BFD, redundancy, graceful-restart or platform-specific verification commands documented for the actual image.

10. Step-by-step troubleshooting

1. Establish the exact failure time from logs/telemetry.
2. Determine whether endpoint reachability changed.
3. Determine whether the BGP TCP session changed state.
4. Determine whether BFD/IGP/next-hop tracking changed first.
5. Inspect the selected BGP path and recursive NEXT_HOP.
6. Inspect RIB installation.
7. Inspect CEF/FIB programming.
8. Check stale/GR/NSR state if HA behavior is involved.
9. Compare the observed event order with the expected convergence design.
10. Correct the smallest proven cause.
11. Repeat the identical fault and measurements.
12. Observe stability after recovery.

12. Post-fix verification

Verify BGP state, selected path, route validity, RIB/FIB installation, end-to-end traffic, negative test, logs/counters, and a stability interval appropriate to the lab. A protocol-state recovery is not accepted as success if forwarding remains broken.

13. Rollback

Revert only the new timer, BFD, tracking, GR/NSR or PIC control introduced by the day. Restore the captured baseline and repeat the original verification set. Roll back immediately for repeated oscillation, unexpected multi-peer resets, persistent stale blackholing, loss of forwarding redundancy, or a platform behavior inconsistent with the documented prerequisite.

6. Baseline configuration

Topic-specific configuration excerpt — not a complete deployable configuration.

router bgp 65010
 neighbor 192.0.2.2 remote-as 65020
 ! Optional lab-only timer override after documenting impact:
 neighbor 192.0.2.2 timers 30 90
 ! Verify exact SendHoldTimer feature support/syntax on the target image.

Exact commands, defaults and support must be verified on the actual IOS XE hardware/software image before execution.

8. Controlled modification

Change the lab timers from the platform default to 30/90 only after predicting reset/failure-detection implications. Do not use aggressive timers as a substitute for BFD where the design objective is subsecond forwarding-path detection.

State the expected detection source, expected BGP event, expected RIB change and expected FIB behavior before applying the change.

9. Fault injection

Illustrative lab — not a real incident.

Drop BGP payloads from EDGE-B toward EDGE-A while allowing EDGE-A-to-EDGE-B traffic. Record which side continues to write, which side stops receiving, and how the session eventually closes. This is a one-way processing experiment, not a generic interface-down test.

11. Root cause and correction

The fault is asymmetric message delivery/processing. Simply lowering the Hold Time may make the symptom appear faster without addressing the asymmetry. Correct the path or remote processing condition; use SendHoldTimer support as an additional protection where the implementation provides it.

14. Deep-dive engineering notes

Negotiation versus local behavior

The Hold Time is negotiated during OPEN exchange; ConnectRetry and SendHoldTimer are local FSM behaviors. An operator should therefore record both the negotiated session values and the local implementation defaults.

Timer tuning is a stability trade-off

Shorter timers reduce failure-detection delay but increase sensitivity to CPU starvation, control-plane congestion and transient loss. Before changing them, measure whether the actual availability objective concerns neighbor process failure, forwarding-path failure, or application-level message processing.

SendHoldTimer fills a specific gap

RFC 9687 addresses a failure mode in which the local system is still capable of sending BGP messages but the remote system is not processing them. That differs from the classic receive-side HoldTimer, which detects that the local system stopped receiving acceptable BGP messages.

Monitoring signals

Capture last-read/last-write timestamps, negotiated hold/keepalive, TCP queue behavior where available, CPU/control-plane health and NOTIFICATION/closure reason. The strongest incident record explains why the timer expired, not merely that it did.

15. Production lessons

• Faster failure detection is useful only when the signal is trustworthy.
• Do not combine multiple fast-convergence mechanisms until each works independently.
• Preserve the distinction between control-plane recovery and forwarding-plane continuity.
• High-availability features often have platform, topology and address-family restrictions.
• Measure actual traffic loss and event ordering instead of advertising a theoretical convergence number.

16. Knowledge check

1. Which stage does today's feature accelerate: detection, BGP decision, RIB update, FIB repair, or more than one?
2. What failure could make the feature produce a false sense of availability?
3. What evidence would prove forwarding recovered before the BGP control plane fully reconverged?

Answers

1. See the day's mechanism: the answer must name the specific accelerated stage rather than saying simply 'BGP convergence.'
2. A false/unstable detection signal, unsupported HA state, invalid stale-route assumption, or absent precomputed forwarding alternate depending on the topic.
3. Timestamped traffic/FIB evidence showing forwarding switched while BGP path processing was still completing.

17. Sources

• RFC 4271: A Border Gateway Protocol 4 (BGP-4) — https://www.rfc-editor.org/rfc/rfc4271.html
• RFC 9687: Border Gateway Protocol 4 (BGP-4) Send Hold Timer — https://www.rfc-editor.org/rfc/rfc9687.html
• Cisco IOS XE 17.x: BGP internal features / timers — https://www.cisco.com/c/en/us/td/docs/routers/ios/config/17-x/ip-routing/b-ip-routing/m_irg-int-features-0.html