BGP failover times were VERY quick-Why?!

[John Blakley]

All,

I thought that the default timers for bgp were 60 and holddown was 180. I may be wrong, but shouldn't a route that falls out of the table be at most put back into the table after 180 seconds (3 min.)?

We tested our failover this weekend, and we shut down our main router to watch our block roll over to our backup router. We lost two packets. I peer with the provider using the same AS on my end (both of my routers are using bgp 1 for instance, and I peer with bgp 2). I'm wondering if this is the reason the failover happened so quickly?

Thanks,

John

[cisco_lad2004]

with 4800 14400, u need to miss 3 hellos.

with 60 14400. u need to miss 240 hellos.

I would keep it simple an stick to x3 ratio, ie 1st line.

[John Blakley]

So, is this a layer 2 functionality, or does it track it at layer 3? It doesn't seem like it's using hello packets to detect the down peer.

Thanks,

John

[cisco_lad2004]

Hmmm...not sure here, I would think it is lower layers.

I am just glad the option is there whn needed.

[John Blakley]

Thanks Sam and Giuseppe for clearing this up for me! I'm definitely going to play with this in gns and see what I come up with. =)

John

[vdadlaney]

Hi, apologize for posting back to this slightly old thread. After reading this thread and another one my understanding is that the BGP timers will not take effect if fast-external-fallover is configured. Would that mean that for whatever reason if fast external fallover is configured but if the keepalives are missed the BGP session will still remain up because the interface hasn't gone down. I have never seen that hence I just want to confirm if that was what was being implied. Pls confirm this. Thx for your help.

[Giuseppe Larosa]

Hello Vikram,

>> but if the keepalives are missed the BGP session will still remain up because the interface hasn't gone down

No, it means that the faster process has the right to change the BGP session state:

if you use very aggressive timers like 1 second for keepalive and 3 seconds for hold it is likely that timers expire before the link is detected down (unless it is a sonet/SDH POS).

timers expiration is a sufficient reason to turn down a BGP session and the device will send a BGP notification to the peer.

if the link is healthy they are able to setup the BGP session again quickly otherwise the BGP session stays down then the link fails.

With default BGP timers the order of events is the opposite:

it is highly likely that link failure detection happens before timers expiration.

In this case bgp fast-external fallover says: the link is down so let's turn down the eBGP session with the peer that is out this link.

Hope to help

Giuseppe

[vdadlaney]

Hi Giuseppe,

Thx for confirming that. Could you please take a stab at another post i I had in the Lan Switching section. It has to do with using NSF through a firewall for BGP. Thx