- NANOG - lists.nanog.org

RE: BGP keepalive/holdtime at GigE exchange
by Lane Patterson 13 Jan '01

13 Jan '01

No, I'm not thinking of cases of gracefully closed sessions, only the behavior of non-gracefully closed sessions. I think the lack of argument here means it's by and large not an important issue, since folks shut down sessions gracefully before doing a maintenance, right? But the answer that "it needs to be at 180 seconds holdtime to maintain routing stability" doesn't seem to hold water since no one's claiming instability caused on private peering links and iBGP sessions due to 10 second interface keepalives ;-) I think the answer is that it just hasn't been important enough to ever change the defaults. > From: Sean Donelan [mailto:sean@donelan.com] > > On Fri, 12 January 2001, Lane Patterson wrote: > > 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. > > What kind of failure modes are you protecting against. The most > common reasons for ending a BGP session will usually include a > TCP CLOSE. There is no problem with a "normal" shutdown because > BGP will immediately withdraw the routes. The timers are for > aborts, such as someone unplugged the neighbor. > > The reason I see for lowering the BGP timer is enabling an upper layer > protocol to ride through the storm. Does Vern Paxson have any data on > how long typical TCP streams survive during periods of > routing instability? > > If a TCP application lasts 180 seconds, and it takes 150 > seconds to recompute > the route table, wouldn't you set the timeout to 30 seconds? > (all numbers > fictional) > > >

1 0

RE: BGP keepalive/holdtime at GigE exchange
by Sean Donelan 12 Jan '01

12 Jan '01

On Fri, 12 January 2001, Lane Patterson wrote: > 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. What kind of failure modes are you protecting against. The most common reasons for ending a BGP session will usually include a TCP CLOSE. There is no problem with a "normal" shutdown because BGP will immediately withdraw the routes. The timers are for aborts, such as someone unplugged the neighbor. The reason I see for lowering the BGP timer is enabling an upper layer protocol to ride through the storm. Does Vern Paxson have any data on how long typical TCP streams survive during periods of routing instability? If a TCP application lasts 180 seconds, and it takes 150 seconds to recompute the route table, wouldn't you set the timeout to 30 seconds? (all numbers fictional)

1 0

route reflectors
by Tony Mumm 12 Jan '01

12 Jan '01

-----BEGIN PGP SIGNED MESSAGE----- Nanog: I am looking back into researching the many flavors of route reflectors, and would like everyone's opinions on what to use. I believe we have hashed through this in the past, but as these things move quickly, it might help to discuss the latest. I would like to consider both sides of the equation, using router based platforms, as well as PC or workstation type reflectors. I'm sure we all have pros and cons to either method. I'm trying to consider the entire range of reflectors, all at varying levels of cost. The gauntlet runs from free software that is entirely unsupported up to support contracts where a software developer will live with you. Just to add my thoughts: I'm leaning towards PC/Unix based reflectors just due to the cost of hardware, especially memory. It is much easier to have parallel and redundant workstations, than it is to have a carrier class router. Thanks for any help, Tony -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com> iQB1AwUBOl9PVpdSAaybdldZAQFZeAL+Jolh40KSPTKaroJi7BH8VEbfdrU3O7w5 pedJqbIe7kQuPSDD4XL0QgXYAKV3AJnKsJfvDYURxs/73ng0phzOVzIgRd0fTy2F MFbfyQIF9IGM2s150WZpC2bdSo17L/AL =j2cB -----END PGP SIGNATURE-----

3 2

Online BGP study material for newbies
by Lionel Lauer 12 Jan '01

12 Jan '01

Per the subject line, could anyone recommend online sources of information that would be helpful for a newbie (approx. CCNA level) learning BGP? Material that covers both common & best practices in a Real-World-compatible manner would be especially helpful. -- W . | ,. w , "Some people are alive only because \|/ \|/ it is illegal to kill them." Perna condita delenda est ---^----^---------------------------------------------------------------

2 1

RE: BGP keepalive/holdtime at GigE exchange
by Lane Patterson 12 Jan '01

12 Jan '01

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@ai.net] > Sent: Friday, January 12, 2001 11:48 AM > To: Lane Patterson > Cc: 'nanog(a)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@equinix.com] > > > Sent: Thursday, January 11, 2001 10:08 PM > > > To: 'nanog(a)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(a)equinix.com> > > > Equinix, Inc. > > > > > > > > >

4 4

RE: BGP keepalive/holdtime at GigE exchange
by Lane Patterson 12 Jan '01

12 Jan '01

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@equinix.com] > Sent: Thursday, January 11, 2001 10:08 PM > To: 'nanog(a)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(a)equinix.com> > Equinix, Inc. >

2 1

RE: Online BGP study material for newbies
by Young, Jason 12 Jan '01

12 Jan '01

> Best BGP reference: > > Internet Routing Architectures, Second Edition > Cisco Press > ISBN 1-57870-233-X > > Common and best practices: > > http://www.cisco.com/public/cons/isp/documents/IOSEssentials.PDF.zip > > Advanced material: > > http://www.cisco.com/public/cons/workshops/ > > All are obviously Cisco-centric but generally applicable. > > -----Original Message----- > From: Lionel Lauer [SMTP:longword@newsguy.com] > Sent: Friday, January 12, 2001 8:07 AM > To: nanog(a)merit.edu > Subject: Online BGP study material for newbies > > > Per the subject line, could anyone recommend online sources of > information that would be helpful for a newbie (approx. CCNA level) > learning BGP? > Material that covers both common & best practices in a > Real-World-compatible manner would be especially helpful. > > -- > W > . | ,. w , "Some people are alive only because > \|/ \|/ it is illegal to kill them." Perna condita delenda est > ---^----^---------------------------------------------------------------

2 1

Tiara v. ASC
by Wilson, David 12 Jan '01

12 Jan '01

Does anyone have any experience with Either of these Vendors products for Multilink Frame Relay or ATM IMA? I have heard that ASC's code/hardware is unstable. Is this true? Any info would be appreciated. Thanks --- David E. Wilson Data Network Engineering Telergy, Inc. 7351 Round Pond Rd North Syracuse, NY 13212 mailto:WilsonD@telergy.net

2 1

OT: Go-Karting in Montreal
by Alex Rubenstein 12 Jan '01

12 Jan '01

A couple of friends of mine are going to MTL this weekend, and I was recommending the go-kart place that MLink brought us to. I can't remember the name tho; any pointers?

1 0

Re: BGP keepalive/holdtime at GigE exchange
by Martin Taylor 12 Jan '01

12 Jan '01

Lane, What about on Cisco's tweaking the global command "ip tcp synwait-time X" so you don't have to wait so long for BGP to notice that the TCP session no longer exists, there is probably a parallel command on Junos. I haven't tried it on BGP, but I would think that it would make BGP (and any other protocol that relies on TCP sessions) much more sensitive. marty > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Lane Patterson > Sent: Friday, January 12, 2001 1:08 AM > To: 'nanog(a)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/ios121/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-routing42/html/bg > p-summary13.html#1015669 > > Cheers, > -Lane > > Lane Patterson <lane(a)equinix.com> > Equinix, Inc. > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com

1 0