[AusNOG] BGP hold timer values

Wed Jan 28 01:18:20 EST 2015

Hi Scott,
BFD isn't line state - BFD is a negotiated session between 2 routers; it is the attached to a protocol like OSPF or BGP. As BFD operates on the data plane then signals the control plane protocol (OSPF, BGP etc) - when BFD detects link loss or packet loss, it will signal to immediately tear down the routing protocol on that interface - and as BFD is configured on both sides of a link - both sides will tear down resulting in outages well under 1 second when convergence of tables can be achieved this fast.
From my experience, when the BGP "update-source" changes state to "down" - most (i use this term carefully) platforms will drop the routing protocol session - but thats not to say that both sides of a BGP session will see this interface transition and behave the same - i.e. IX networks.

Hi Alex,
On my convergence point there - when tables can be converged that fast - if your hardware (or software) router could not converge routing tables fast enough you would have experienced something like this. What are you routing on? (hit me up offlist if this is sensitive).
It could also be configuration related - (a) on your gear, a second pair of eyes (usually) never hurts - (b) with a second provider, i have suffered URPF issues with some upstreams in the past when traffic failed over to them due to a non updated configuration their side.

Tom

On 27 Jan 2015, at 11:48 pm, Scott O'Brien <scott at scottyob.com<mailto:scott at scottyob.com>> wrote:

I can see how BFD and lower hold & keep-alive messages help convergence time (obviously) but am wondering how useful it is in practice?  Do most people peer with a directly connected interface on routers or through an intermediate switch?  I would be expecting most would peer with their providers using links on the router itself and would be taking advantage of the (on by default in Cisco world) fast-external-fallover.  Obviously this relies on the interface going down (so wouldn’t work with Transit over Megaport for instance or switch in between) and doesn’t help a dying control plane issue but wouldn’t the default behaviour be pretty good in helping convergence in most typical eBGP setups & failures with this feature?

~ Scotty O

On 27 Jan 2015, at 11:19 pm, Alex Samad - Yieldbroker <Alex.Samad at yieldbroker.com<mailto:Alex.Samad at yieldbroker.com>> wrote:

Hi

I will have to monitor that.

We suffered from an outage recently, with a provider we have 2 links with.  We have multiple providers.
As a review of the incident the business asked about the 3m hold timer. In theory the way I read it, is the routes could be held for up to 3 min whilst the link is down…

One of the questions was why did it take soo long ~ 8-9min for traffic to appear on the other link.  Waiting for feedback on that
I am presuming with a lower hold timer/keep alive I can get pretty fast response as its only on this providers network I am failing over.

Alex

From: Tom Berryman [mailto:Tom at connectivityit.com.au]
Sent: Tuesday, 27 January 2015 11:09 PM
To: Alex Samad - Yieldbroker
Cc: David Hughes; ausnog at lists.ausnog.net<mailto:ausnog at lists.ausnog.net>
Subject: Re: [AusNOG] BGP hold timer values

There is a bit more than just a few extra packets (as your cost) - BGP can/does have notable CPU impact on low-mid range routing gear.

With eBGP, you are talking propagation of your routes to the internet, so not all of the internet is going to see your changes for maybe up to 180 seconds. That said, it's likely most of it will be sooner than that.

Tom

On 27 Jan 2015, at 11:01 pm, Alex Samad - Yieldbroker <Alex.Samad at yieldbroker.com<mailto:Alex.Samad at yieldbroker.com>> wrote:

Hi

Okay its eBGP, currently have 4 providers, some with multiple connections. So I am thinking 6 / 20 might be good for me, business requirement for approx. 30sec response.
I am presuming all I am looking at is extra BGP packets .. every 6 sec compared to 1 min..

Alex

-----Original Message-----
From: David Hughes [mailto:david at hughes.com.au]
Sent: Tuesday, 27 January 2015 9:37 PM
To: Alex Samad - Yieldbroker
Cc: ausnog at lists.ausnog.net<mailto:ausnog at lists.ausnog.net>
Subject: Re: [AusNOG] BGP hold timer values

I gave a lightning talk about this sort of thing a while ago at an APRICOT.  I just
googled to find the slides and can now see just how many years ago it was.
Gotta say I'm feeling old :)

But, it's probably still relevant although the defaults may have changed.  This
reflected what we were running at the time - and we were trying to be
pretty aggressive.

http://archive.apnic.net/meetings/21/docs/sigs/routing/routing-
pres-hughes-bgp.pdf

For reference I'm currently happy to run

eBGP
: 10 / 30
iBGP
: 5 / 15

And I'd run this even to a single upstream.  If it fails at least you'll have
something in your logs to say why you fell off the net for a while.  Silent
failures are a bugger to troubleshoot.

Thanks

David
...

On 27/01/2015, at 6:47 PM, Alex Samad - Yieldbroker
<Alex.Samad at yieldbroker.com<mailto:Alex.Samad at yieldbroker.com>> wrote:

Hi

I'm wonder what is considered "best practice" or good/responsible hold
timer values for BGP.

Currently I'm set at 3m, but I am considering lowering this to 30s and keep
alive down to 20s, potentially even lower. Or if possible to use BFD & BGP,
what's the uptake on BFD ?

Alex
_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

_______________________________________________
AusNOG mailing list
AusNOG at lists.ausnog.net<mailto:AusNOG at lists.ausnog.net>
http://lists.ausnog.net/mailman/listinfo/ausnog

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ausnog.net/pipermail/ausnog/attachments/20150127/b509e10c/attachment.html>