[j-nsp] BGP route-reflection question

[Danny McPherson]

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