North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical RE: BGP keepalive/holdtime at GigE exchange
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:[email protected]] > Sent: Friday, January 12, 2001 11:48 AM > To: Lane Patterson > Cc: '[email protected]' > 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:[email protected]] > > > Sent: Thursday, January 11, 2001 10:08 PM > > > To: '[email protected]' > > > 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 <[email protected]> > > > Equinix, Inc. > > > > > > > > >
|