BGP convergence time

Question

Hello,
Recently I have been experiencing some problems with BGP convergence taking longer then expected.
I have 3 upstream peers, and for awhile I had the best one local pref'ed down, so that things were more balanced.
I took away those local preference configurations, so that my ibgp routers (6) pretty much learn 250,000 routes from the 1 peer, and a very small amount of routes from the other 2, the 1 peer is just that well connected.
If i soft shut down the peer that has all of the routes as the best path, convergence cane take from 3-4 minutes, and causes some destinations to be unreachable during those times. Prior to the change, when my routes were balanced because of filtering, where I may learn 100,000 routes from each peer etc, things converged much quicker.
My question is, can Cisco routes just not handle pulling out 250,000 routes from 5-6 downstream ibgp peers quickly?
I am running 6500s and 7600s with sup720, so I would think the reason is not bad hardware that can not handle it, i would just expect these routers to be able to handle full tables a bit better, when it comes to sending the remove messages to its downstream ibgp peers faster.
Is there a way to make that go smoother, with maybe route reflectors? I have no used them before so am not to familar with how they work low level, just looking for ideas.
Thanks.

Answer 1

Hello Jason,
>> If i soft shut down the peer that has all of the routes as the best path, convergence cane take from 3-4 minutes, and causes some destinations to be unreachable during those times. Prior to the change, when my routes were balanced because of filtering, where I may learn 100,000 routes from each peer etc, things converged much quicker.
It takes times to install the new routes: now when the preferred peer for 250,000 routes fail all 250,000 routes have to be withdrawn for each prefix a new BGP best path has to be chosen and propagated.
Each BGP update takes space in a BGP update packet and a BGP update packet has a maximum size.
The protocol has its own dynamics and cannot convergence in zero seconds: the more best BGP paths change the more the protocol has to work.
So what you see is the result of having preferred all the routes of a single peer: this can be a resonable choice but it is a worse case from the reduncancy point of view in comparison to having as best routes one third of prefixes via peer1, oner third via peer2, one third via peer3.
BGP Route Reflector servers are a good tool for scalability, they are of limited help in reducing convergence time.
Hope to help
Giuseppe