[126351] in North American Network Operators' Group
Re: BGP and convergence time
daemon@ATHENA.MIT.EDU (Scott Weeks)
Wed May 12 17:43:34 2010
Date: Wed, 12 May 2010 14:41:00 -0700
From: "Scott Weeks" <surfer@mauigateway.com>
To: <nanog@nanog.org>
Reply-To: surfer@mauigateway.com
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--- danny@tcb.net wrote:
From: Danny McPherson <danny@tcb.net>
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.
This isn't a negotiation?
: IIRC, neither J or C reset the session with the timer change, but the
: new holdtimer expiry value doesn't take effect until then.
We use Alcatel 7750s. Damn thing just resets the session; no warning, no nothing. :-(
: 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.
I have been looking for info on the negative impact on a router by increasing the keepalive frequency to a high rate. I'm sure it's minimal for a few BGP peers, but I could imagine with a lot of peers it's a non-zero impact.
scott
