BGP hold time
termHow long a BGP speaker waits without hearing from its peer before it declares the session dead and closes it.
Each side offers a Hold Time in its OPEN message, and RFC 4271 section 4.2 makes both use the smaller of the two; KEEPALIVE messages stop it from expiring. It sets how long a silent peer can go unnoticed, up to 90 seconds with the suggested default, which is why faster detection is left to a dedicated protocol such as BFD.
On receiving an OPEN, a speaker must set its Hold Timer to the smaller of its own configured Hold Time and the one received. The value must be zero or at least three seconds, and the other side has no veto: an implementation may only reject the connection on the basis of the Hold Time. A router configured for 180 seconds whose peer offers 9 therefore runs at 9.
RFC 4271 section 10 suggests 90 seconds for the Hold Time and a third of it for the keepalive interval; a KEEPALIVE is a bare 19-octet header and must not be sent more often than once per second. Implementations set their own defaults and controls. FRRouting configures both values per neighbour, keepalive first, and offers a minimum hold time below which it refuses to establish a session.
When nothing arrives within the Hold Time, the speaker sends a NOTIFICATION with the Hold Timer Expired error code and closes the connection, and a verified erratum (ID 2838) adds that it deletes all routes associated with that connection. With the suggested 90 seconds, a peer that has gone silent can keep its routes in use for up to 90 seconds before that happens.
Also known as: hold time, holdtime, hold timer, keepalive interval, bgp keepalive, hold timer expired