 |
|
Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
|
|
|
Custom Search
|
|
BGP Connectivity Maintenance: Keepalive Messages
(Page 1 of 2)
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.
|
| |||||||||||||||||||
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.