06-28-2009 05:27 AM - edited 03-04-2019 05:15 AM
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
Solved! Go to Solution.
06-29-2009 11:41 AM
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.
06-29-2009 11:30 AM
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
06-29-2009 11:36 AM
Hmmm...not sure here, I would think it is lower layers.
I am just glad the option is there whn needed.
06-29-2009 12:05 PM
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
07-24-2009 10:18 AM
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.
07-24-2009 10:58 AM
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
07-24-2009 01:46 PM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide