Help with BGP convergance.....

Unanswered Question
Jun 25th, 2010

We have a WAN on MPLS that is using

BGP. We are getting 25 to 35 second convergance but we need to do better. I have the router config's and a drawing of the

network if someone thinks they could help us improve this. Thanks in advance.......

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
John Blakley Fri, 06/25/2010 - 12:03

Is it eBGP or iBGP that you're using? You can change timers per neighbor to help with convergence. Something like:

neighbor x.x.x.x timers 5 15

BGP will select the lower timer of the 2 peers (meaning if your peer is 60 180 (default), it will scale down to match yours.)

There is a recommendation for not going lower than 20 seconds because it can increase the chance of bgp flapping.



JamesBrockman Fri, 06/25/2010 - 12:16

We have adjusted the timers but we still see the 25 to

35 seconds to converge.....I wonder if we are missing something in the config????

John Blakley Fri, 06/25/2010 - 12:53

Gonna take me a little time to look at this. Where are these routers in your diagram? I don't see the AS listed that you have in the configs.


John Blakley Fri, 06/25/2010 - 12:58

There are a couple of things that you can try that I don't see in your config. There's an option in BGP called fall-over. It helps speed up convergence on the

detection of a loss of the peer. I would apply it to the iBGP peers and see if that helps with your convergence. You can also try to enable graceful-restart to see if that helps as well.



JamesBrockman Fri, 06/25/2010 - 13:04

We looked at fall over but it said it needed host routes and not didn't seem to fit with our design....please take all the time you need.....I get off work between 5 and 5:30 EST....I'll most likely be back on tonight from home.....this amusment never ends.....

JamesBrockman Mon, 06/28/2010 - 05:11


     I went back in and looked at the timers again.....I reset them and it inproved the convergance greatly....we now see 6-7 seconds until the network convereges....I'm not sure we could do better than today more testing ....thanks for your help...


John Blakley Tue, 06/29/2010 - 07:26


6-7 seconds is pretty normal. Are these ethernet interfaces and are you seeing the convergence between ibgp peers? If so, you could try to bring the timers down to 1 and 3 for hold down.



JamesBrockman Tue, 06/29/2010 - 08:18

No these are the serial MPLS network.....I had adjusted the timers to

1 3 3 and it worked great....we have  celluar for our backup which seems to hold the routes for at least a min sometimes longer so I'm not sure the timers are even an issue...since it doesn't "flap" once it's on the cell it stays there for so far at least a min.....I think I get the concept of the timers but do you have a good/easy/layman way to explain them to others...they are asking me to justify why I can have them set so low.....we are using eigrp from router 2 up to the 3g router to speed the convergance and it works really you think I could get the same resault from ospf?

again thanks for your help


John Blakley Tue, 06/29/2010 - 08:45

The 1 is the keepalive and the 3 is the hold timer. When bgp doesn't receive a keepalive within 3 seconds, it considers the neighbor down and fails over to the backup (less preferred) routes. So BGP sends the keepalive every 1 second, and if it doesn't receive a keepalive within 3 seconds it considers the neighbor down.

You can see this by doing a "sh ip bgp neighbor x.x.x.x | inc Last read"

Last read 00:00:18, last write 00:00:11, hold time is 180, keepalive interval is 60 seconds

The default is 60 and 180 (3 minutes) for BGP, and the argument for changing timers per neighbor is usually that you shouldn't need to change them, but I have them changed in my network as well on iBGP neighbors. My serial side on our MPLS network converges fairly fast. When an interface failure is detected, I believe our provider has the "fast-external-failover" feature enabled. If you have access to both sides (with no provider in the middle) of your MPLS network, you may want to enable that feature on both ends of your serial link to see if that helps with your convergence without jacking around with the timers. Otherwise, you should be okay.


* Please rate helpful posts *

JamesBrockman Tue, 06/29/2010 - 09:06


I'll ask about the "fast-external-failover". That's about as clean as it can get for an explanation..... To test this we are just shutting down the serial that a good test? Does it simulate a network outage or is there a better way to test this???

Thanks again


James Brockman

Network Engineer

Ahold Account

HP Enterprise Services

Telephone +1 717.240.5568

Email [email protected]

1149 Harrisburg Pike, Carlisle, PA 17013

John Blakley Tue, 06/29/2010 - 09:12

Yes. When you shut the serial side down, the other side of the link will go down. You can also do a hard failover by removing the cable.

John Blakley Tue, 06/29/2010 - 09:20

More than likely not since bgp timers are controlling convergence. I usually test mine by shutting the interface.

francisco_1 Tue, 06/29/2010 - 09:32


BGP keepalives are important to validate BGP sessions health and to avoid routing blackholes.

if you are setting your keepalive interval & holddown timers in production you need to be very careful. Setting the timers  too small results in fast  peering deactivateion detection and lead to false positives and disruption of BGP session  and exessibe route flapping,

For fast-external-failover, this feature is enable by default for eBGP sessions using the BGP process command bgp fast-external-failover and used for point-point links on a none-shared link when the peers are directly connected. Using it on NBMA and ethernet interfaces might be inefficient.

A more advance version is called fast peering session deactivation which can be setup using the neighbor command "neighbor fall-over. This feature applies to both iBGP & eBGP and does not rely on interface state instead uses IGP. Once the IGP route disappear, the BGP session gets immediately torn down and used for none-direct conencted peers.



This Discussion