skip to content

How do two BGP peers settle on a hold time, how often should KEEPALIVEs flow, and what happens when the hold timer expires?

level: middleimportance: should knowfreq 30%

answer

  1. proposed in OPEN, agreed per session
  2. the smaller offer wins
  3. zero, or three seconds and up
  4. a third of it between KEEPALIVEs

basics

~20 s

Each BGP peer proposes a hold time in its OPEN and both use the smaller, which must be zero or at least 3 seconds. KEEPALIVEs flow about every third of it; if nothing arrives in time, the session closes with Hold Timer Expired.

solid answer

~50 s

Each speaker puts its configured `Hold Time` in its `OPEN`; on receipt, RFC 4271 says the speaker MUST use the smaller of its own value and the peer's. The value MUST be zero or at least 3 seconds, so an offer of 1 or 2 seconds is rejected with an OPEN Message Error, subcode Unacceptable Hold Time. RFC 4271 suggests 90 seconds as the default and a `KEEPALIVE` at most every third of the hold time, never more than one per second. Every `KEEPALIVE` or `UPDATE` received restarts the hold timer. If it runs out, the speaker sends a `NOTIFICATION` with the Hold Timer Expired code, closes TCP, deletes the routes learned from that peer and returns to `Idle`. A negotiated hold time of zero turns the mechanism off: no periodic KEEPALIVEs, and the session never times out.

go deeper

for a junior

Recall that peers agree a hold time in their OPEN messages and send KEEPALIVEs so it never runs out. If it does, the session closes.

for a middle

Explain the negotiation: the smaller offer wins, zero or at least 3 seconds, KEEPALIVE at about a third, and the Hold Timer Expired NOTIFICATION with a return to Idle.

for a senior

Discuss choosing the value: long timers leave a silent failure blackholing traffic, short ones drop healthy sessions under load, and a separate fast detector is the usual way out.

for a principal

Weigh detection speed against stability across a whole estate: one timer policy for every peer type rarely fits, and the cost of a false session drop is every route on it.

## What the hold timer is for A **BGP session** runs over a long-lived TCP connection, and RFC 4271 states that BGP does not use a TCP keep-alive mechanism to decide whether a peer is reachable. Instead it uses its own pair of timers: - The **HoldTimer** is the longest a speaker will wait between successive KEEPALIVE or UPDATE messages from its peer before it declares the peer dead. - The **KeepaliveTimer** paces the speaker's own KEEPALIVE messages so that the peer's HoldTimer never runs out while the session is healthy. A **KEEPALIVE** is the smallest BGP message: the 19-octet header and nothing else. ## How the hold time is negotiated The hold time is agreed once per session, inside the OPEN exchange: 1. Each speaker puts its configured hold time, in seconds, into the 2-octet **Hold Time** field of its OPEN. 2. On receiving the peer's OPEN, the speaker **MUST use the smaller** of its own configured value and the value received. 3. The value **MUST be zero or at least three seconds**. A speaker MUST reject an offer of 1 or 2 seconds, and MAY reject any offer it finds unacceptable; it does so with a NOTIFICATION carrying the OPEN Message Error code and the **Unacceptable Hold Time** subcode. 4. Until the OPEN arrives, the speaker in OpenSent does not know the result, so it waits with a large value; RFC 4271 suggests 4 minutes. RFC 4271 suggests a default **HoldTime of 90 seconds** and a **KeepaliveTime of one third** of the hold time. It also says KEEPALIVEs MUST NOT be sent more often than once per second. The 90-second figure is a suggestion, so implementations ship their own defaults. ## Worked examples | Speaker A offers | Speaker B offers | Session hold time | KEEPALIVE every (one third) | |---|---|---|---| | 90 s | 90 s | 90 s | about 30 s | | 90 s | 30 s | 30 s | about 10 s | | 180 s | 9 s | 9 s | about 3 s | | 90 s | 0 | 0, unless A rejects it | none | | 90 s | 2 s | session refused | none | In the second row, the speaker that wanted 90 seconds still detects a silent peer within 30 seconds, because both sides use the smaller value. In the fourth row, zero is smaller than 90, so the session runs with the timers off unless speaker A chooses to reject the offer. ## What expiry does Each KEEPALIVE or UPDATE received restarts the HoldTimer. When the timer does reach zero, RFC 4271 has the speaker: 1. send a **NOTIFICATION** with the **Hold Timer Expired** error code (code 4); 2. drop the TCP connection; 3. delete the routes learned from that peer and recompute its best paths, telling its other peers about withdrawals or new best routes; 4. move its state machine to **Idle**, from which a new start begins the setup again. Expiry is the protocol's answer to a peer that **fails silently**: the far end loses power, or a path through an intermediate switch breaks while the local interface stays up. A peer that closes TCP cleanly is noticed at once, because the TCP connection fails; many implementations also react at once when a directly connected interface goes down, which is an implementation choice rather than an RFC 4271 rule. ## Trade-offs in choosing a value - **Long hold time.** A silent failure blackholes traffic for up to the full hold time before routes are withdrawn; with 90 seconds that is a long outage. - **Short hold time.** A few seconds detects failure faster, but a busy speaker that is late with a KEEPALIVE can tear down a healthy session and withdraw every route on it, which is often worse than the failure it was guarding against. - **Zero.** No KEEPALIVEs and no timeout. A dead peer is noticed only when TCP itself reports failure, for example when data sent to it is never acknowledged, so a quiet session can sit on stale routes. - **A separate failure detector.** Many networks keep a conservative hold time and attach a lightweight liveness protocol such as BFD to the session for sub-second detection; how BFD does that is its own subject. ## Common mistakes - Thinking the larger offer wins, or that each side keeps its own value: both use the smaller. - Treating 90 seconds as a protocol rule rather than RFC 4271's suggested default. - Forgetting that an UPDATE restarts the HoldTimer just as a KEEPALIVE does. - Assuming a hold time of zero means "expire immediately": it means "never expire".

  • Why does RFC 4271 forbid a BGP hold time of 1 or 2 seconds yet allow zero?
    Zero is a deliberate off switch: no periodic KEEPALIVEs and no expiry. RFC 4271 does not spell out why the floor is 3 seconds, but KEEPALIVEs may not be sent more than once per second and are suggested at a third of the hold time, so 3 seconds is the smallest value that fits that rate. A speaker MUST reject 1 or 2 with Unacceptable Hold Time.
  • After a BGP hold timer expires, what happens to the routes learned from that peer?
    The speaker closes the connection and deletes the routes it learned from that peer. Its routing table entries through that peer become invalid, it recomputes best paths for those destinations, and it sends its other peers either withdrawals or the new best routes. Traffic shifts to alternative paths, or is dropped if none exist.

saying these in an interview costs you the question

  • When BGP hold times differ, the larger offer is used so neither side drops early.
  • A BGP hold time of zero makes the session expire immediately.
  • Only KEEPALIVE messages restart the BGP hold timer; UPDATEs do not.
  • BGP relies on TCP keep-alive probes to detect a dead peer.
  • The 90-second hold time is mandatory in RFC 4271.