BGP keepalive/holdtime at GigE exchange

Fri Jan 12 19:59:38 UTC 2001

Hmm, I know there are a lot of overburdened BR's out there, but
since this is set on a per-neighbor basis, there should at least
be room for some selective optimization.  It seems a bit crazy
to think that each time there's a BR maintenance/reboot at an IXP,
peers will continue to send to the bit bucket in the sky for 180+
seconds.

> -----Original Message-----
> From: Deepak Jain [mailto:deepak at ai.net]
> Sent: Friday, January 12, 2001 11:48 AM
> To: Lane Patterson
> Cc: 'nanog at merit.edu'
> Subject: RE: BGP keepalive/holdtime at GigE exchange
> 
> 
> 
> 
> The problem I have seen with setting BGP timeouts that low is 
> when peering
> with overloaded or slow/old routers. Often they will "pause" their BGP
> activity while they are actively peering or repeering across their
> internal or external network. The low times will then cause 
> more timeouts
> before the fabric has stablized. 
> 
> Deepak Jain
> AiNET
> 
> On Fri, 12 Jan 2001, Lane Patterson wrote:
> 
> > 
> > Hmm, many folks didn't seem to understand the context here.
> > 
> > fast-external-fallover doesn't apply if a peer BR across a GigE
> > exchange dies...you've still got link on your Gig port, so there
> > is no link level indication of failure.
> > 
> > tweaking tcp timers is not the right approach...BGP explicitly
> > has a keepalive for this exact purpose, when peering dies but
> > your interface stays up.
> > 
> > the best non-radical suggestion so far is to simply tweak your
> > keepalive to 10 and holdtime to 30 seconds, to bring this in line
> > with the granularity of direct-connected peer interface or 
> IGP metrics.
> > 
> > Do people do this?  Do people have problems doing this?
> > 
> > Do any folks do less than this on their eBGP peers, and at
> > what tradeoff expense.
> > 
> > This is the old issue of finding the right operationally sane
> > timeouts, not too high, not too low.  The defaults clearly
> > seem too high, yet I haven't seen many cases where folks set 
> > these down :-)
> > 
> > Cheers,
> > -Lane
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: Lane Patterson [mailto:lpatterson at equinix.com]
> > > Sent: Thursday, January 11, 2001 10:08 PM
> > > To: 'nanog at merit.edu'
> > > Subject: FW: BGP keepalive/holdtime at GigE exchange
> > > 
> > > 
> > > 
> > > 
> > > 
> > > I am looking for operational BCP feedback on common practice 
> > > for tweaking
> > > down BGP holdtime/keepalive across GigE exchange points, 
> since a peer
> > > could go down on the other side of the GigE switch without a 
> > > corresponding adjacency change seen on your BR.  The thought is
> > > to make down peers known as fast thru a GigE exchange as 
> they would 
> > > be over a POS private peer interface.
> > > 
> > > The current defaults are pretty gross, and much worse than the
> > > ISIS hello and interface keepalive defaults of 10 seconds.
> > > 
> > > IOS12.x: neighbor [ip-address | peer-group-name] timers 
> > > keepalive holdtime
> > > 	holdtime: default 180 seconds	
> > > 	keepalive: default 60 seconds
> > > 
> > > http://cco.cisco.com/univercd/cc/td/doc/product/software/ios12
> > > 1/121cgcr/ip_r
> > > /iprprt2/1rdbgp.htm#xtocid8553
> > > 
> > > JunOS 4.2: 
> > > 	holdtime: default 90 seconds
> > > 	keepalive: default one third of holdtime
> > > 		
> > > https://www.juniper.net/techpubs/software/junos42/swconfig-rou
> > > ting42/html/bg
> > > p-summary13.html#1015669
> > > 
> > > Cheers,
> > > -Lane
> > > 
> > > Lane Patterson <lane at equinix.com>
> > > Equinix, Inc.
> > > 
> > 
> > 
> 
> 