BGP and convergence time

Wed May 12 21:41:00 UTC 2010

--- danny at tcb.net wrote:
From: Danny McPherson <danny at 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