The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Internet Layer (OSI Network Layer) Protocols            9  TCP/IP Routing Protocols (Gateway Protocols)                 9  TCP/IP Exterior Gateway/Routing Protocols (BGP and EGP)                      9  TCP/IP Border Gateway Protocol (BGP/BGP-4)                           9  BGP Detailed Messaging, Operation and Message Formats

BGP Route Information Exchange: Update Messages 1 2 BGP Error Reporting: Notification Messages

Once a BGP connection is established using Open messages, BGP peers will initially use Update messages to send each other a large amount of routing information. They will then settle into a routine, where the BGP session is maintained, but Update messages are sent only when needed. Since these updates correspond to route changes, and route changes are normally infrequent, this means many seconds may elapse between receipt of consecutive Update messages.

While a BGP peer is waiting to hear the next Update message, it remains sort of like a person who has been put “on hold” on the telephone. Now, seconds may not seem like much to us, but to a computer they are a very long time. Like you, a BGP speaker that is put on hold for too long might become impatient, and start to wonder if maybe the other guy hung up on them. Computers don't get offended at being put on hold, but they might wonder if perhaps a problem arose that led to the connection being interrupted.

To keep track of how long it has been on hold, each BGP device maintains a special hold timer. This hold timer is set to an initial value each time its peer sends a BGP message. It then counts down until the next message is received, when it is reset. If the hold timer ever expires, the connection is assumed to have been interrupted and the BGP session is terminated.

The length of the hold timer is negotiated as part of session setup using Open messages. It must be at least three seconds long, or may be negotiated as a value of zero. If zero, the hold timer is not used; this means the devices are “infinitely patient” and don't care how much time elapses between messages.

To ensure that the timer doesn't expire even when no Updates need to be sent for a long while, each peer periodically sends a BGP Keepalive message. The name says it all: the message just keeps the BGP connection alive. The rate at which Keepalive messages is sent is implementation-dependent, but the standard recommends that they be sent with an interval of one-third the value of the hold timer. So if the hold timer has a value of three seconds, each peer sends a Keepalive every second (unless it needs to send some other message type in that second). To prevent excess bandwidth use, Keepalives must be sent no more often than once per second, so that is the minimum interval even if the hold timer is shorter than three seconds.

BGP Route Information Exchange: Update Messages 1 2 BGP Error Reporting: Notification Messages