BGP keepalive/holdtime at GigE exchange
Lane Patterson
lpatterson at equinix.com
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.
> > >
> >
> >
>
>
More information about the NANOG
mailing list