Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

iBGP Timers - Convergence Requirements


Hope everyone is well.

Please see attached diagram, I have a requirement, to peer BGP between two companies, and it needs to be in an active/standby design.

Now, Site 2 and Site 3 (in one BGP as) peer to Site 1 in another BGP as.

But, the only way to get from Site 2 to Site 3 is via Site 4, and iBGP runs over the two WAN links.

Site 2 to site 1 is the active path because of MED settings set via a route-map on inbound received prefixes.

If WAN link 1 goes down, then the IGP would start to converge from site 4 to site 3, but in site 3, BGP table, it would have an entry via iBGP back to site 2 and thus cannot converge until iBGP is torn down.

2 Questions,

1. Is this quite a common scenario.

2. What is the best way to better convergence, so that iBGP breaks on loss of any of the WAN links. ie, is there any problem with bringing down iBGP timers to just above the eBGP timers, or is there a better and more efficient way of doing this?

Many thx indeed,



Re: iBGP Timers - Convergence Requirements


I feel it may be due to scenario that u haven't configure the ibgp mesh in the transis AS and synchroziation is also diabled. When u r telling the route is available in BGP table, pls. see whether the nexthop attribute is showing some ip address or inaccessible. If it is inaccessible, it is perfectly okei, becz it won't enter into the routing table.

Rate if it does,



Re: iBGP Timers - Convergence Requirements

This is a very common issue using IBGP or even multihop ebgp. Since it is not a directly connected link it has no way to detect it went down and is dependant on timers.

It should not hurt to reduce the timers. The timers in BGP are set so high because of the size of routing table that are normally used. In most interanal networks the size of the routing table won't be a issue.

The only other way I have seen this done is not to use IBGP at all. You redistribute the EBGP routes into EIGRP with different metrics which solves path selection from network to network in your example. To solve to issue you can use conditional advertisement and base the condition on having a EIGRP route to the loopback address on R1 in your example. This way R2 would only advertise the routes if it did not have a route to the loopback of r1. The only thing that has issues with this type of design is that anything directly connected to r2 would alway take the EBGP connection and would come back via router 1 giving you asyncronus routing.

I would just change the timers as you propose.

New Member

Re: iBGP Timers - Convergence Requirements

Thanks to all for the input.

I like the idea of the cond advertisments, and no iBGP but I have had problems with conditional advertisments and the BGP scan timer before, and there is currnetly a TAC case open for this as convergence on our code was a bit of an issue because of the scan timer problem.

I like the way you do this with a route to a loopback :)

Also, Maybe as you recommend, bring IBGP timers down to 3 and 9.

Could you comment on these timers? Are they too agressive? Or would you say they are OK?

Many thx again for the help,


New Member

Re: iBGP Timers - Convergence Requirements

Hello all,

Thinking about this, EIGRP timers are default as 5/15 so maybe as I need to emulate this, Should I set iBGP hello timers to the same or slightly higher, so that if a circuit flaps, BGP remains stable?


There are both L2 and L3 timers to consider here.

serial HDCL keepalive timers are typically 10/30 which is no good for fast convergence, then EIGRP hello timers 5/15, and now iBGP hello timers x/xx Maybe set to 7/21

Fun :)

Are these timers too aggressive for iBGP and if anyone has any opinion on this, that would be great.

Kind regards,