[j-nsp] BGP route-reflection question

[Hannes Gredler]

On Wed, May 28, 2003 at 06:04:33PM -0600, Danny McPherson wrote:
| On 5/28/03 5:23 PM, "'Dmitri Kalintsev'" <dek at hades.uz> wrote:
| 
| > P.S. I've noticed yesterday that the other vendor is now also says that
| > having more than one RR in the same cluster is "not recommended". *Sigh*,
| > the world has changed, hasn't it? ;)
| 
| Folks should be careful here, I'm not sure that this is truly a
| "recommended" design, per se, as it can effect lots of things significantly.
| For example, less optimal BGP update packing and subsequently, slower
| convergence & much higher CPU resource utilization, etc...  In addition, it
| increases Adj-RIB-In sizes [on many boxes] and can have a significant impact
| on steady state memory utilization.  Imagine multiple levels of reflection
| or more than two reflectors for a given cluster, etc..  The impact of
| propagating and maintaining redundant paths with slightly different
| attribute pairings, especially in complex topologies, should be heavily
| weighed.
| 
| What I'd _probably recommend is a common cluster_id for all RRs withing a
| cluster, a full mesh of iBGP sessions between clients and loopback iBGP
| peering everywhere such that if the client<->RR1 link fails there's an
| alternative path for the BGP session via RR2 (after all, the connectivity is
| there anyway) and nothings disrupted.  There are lots of other variable to
| be considered as well, but IMO, simply using different cuslter_ids isn't a
| clean solution.

danny,

most of the BGP scaling properties are bound to memory size, you are right:

however, what i fail to see is why path diversity is negatively impacting convergence;
what i have seen to far is contrary: a healthy path diversity speeds
up convergence;

of course many paths do cost memory; so the main challenge
is to convince "the other vendor" to ship proper memory with their boxes and
not to tweak the design of the routing mesh to the limitations of a single
implementation;

typically the design lives much longer than a single boxes' lifespan ;-)

/hannes