--- zeusdadog@gmail.com wrote: From: Jay Nakamura <zeusdadog@gmail.com> AT&T doesn't seem to be even willing to change BGP timers. If anyone have been able to talk AT&T or Qwest in doing so, it would really help to ---------------------------------------- You set the timers on your side and the two sides negotiate then select the lowest timer settings. The BGP session automatically hard resets on some equipment when changing the timers, so be aware of that. scott
On 12 May 2010 02:36, Scott Weeks <surfer@mauigateway.com> wrote:
You set the timers on your side and the two sides negotiate then select the lowest timer settings. The BGP session automatically hard resets on some equipment when changing the timers, so be aware of that.
Hold timers are negotiated in the OPEN message, I seem to remember, so surely you *have* to hard reset the connection to get the lower holdtime? M
On Wed, May 12, 2010 at 11:02 AM, Matthew Walster <matthew@walster.org> wrote:
On 12 May 2010 02:36, Scott Weeks <surfer@mauigateway.com> wrote:
You set the timers on your side and the two sides negotiate then select the lowest timer settings. The BGP session automatically hard resets on some equipment when changing the timers, so be aware of that.
Hold timers are negotiated in the OPEN message, I seem to remember, so surely you *have* to hard reset the connection to get the lower holdtime?
I just tested this and, yes, with Cisco to Cisco, changing the setting won't reset the connection but you have to reset the connection to have the value take effect. I need to look up what happens when two sides are set to different values and which one takes precedent.
On May 12, 2010, at 9:40 AM, Jay Nakamura wrote:
I just tested this and, yes, with Cisco to Cisco, changing the setting won't reset the connection but you have to reset the connection to have the value take effect. I need to look up what happens when two sides are set to different values and which one takes precedent.
The holdtime isn't technically negotiated, both sides convey their value in the open message and the lower of the two is used by both BGP speakers. IIRC, neither J or C reset the session with the timer change, but the new holdtimer expiry value doesn't take effect until then. One other thing to note is that by default, keepalive intervals in those implementations are {holdtime/3}. Normally, if you're setting holdtime to something really lower (e.g., 10 seconds) you might want to increase the frequency of keepalives such that the probability of getting one through in times of instability rise. In particular, congestion incurred outside of BGP, as update messages themselves will serve as implicit keepalives, and with the amount of churn in BGP, empty updates (keepalives) are rare for most speakers with a global BGP view. -danny
On Wed, May 12, 2010 at 09:52:48AM -0600, Danny McPherson wrote:
The holdtime isn't technically negotiated, both sides convey their value in the open message and the lower of the two is used by both BGP speakers. IIRC, neither J or C reset the session with the timer change, but the new holdtimer expiry value doesn't take effect until then.
Rest assured J will always reset the session if given given half a chance, and changing your holdtime is more than half. :) One thing I find interesting is that most other protocols will err on the side of caution and use the higher of two values like this when negotiating between two parties, but BGP does the opposite. I still run into bad bgp implementations which can't keep up with my 30 sec hold timers all the time *coughghettoequinixrouteservercough*. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
participants (5)
-
Danny McPherson -
Jay Nakamura -
Matthew Walster -
Richard A Steenbergen -
Scott Weeks