[j-nsp] BGP route-reflection question

[Niels Bakker]

> 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? ;)

* danny at tcb.net (Danny McPherson) [Thu 29 May 2003, 02:05 CEST]:
> 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.

I concur with this.  My experience has taught me similar things.

Divide your network into a few hubs, nominate two routers as route
reflectors in each, give each pair identical cluster ID's, configure
full iBGP mesh between all route reflectors, have every router in each
cluster peer with the two route reflectors only.  Choose the route
reflectors as it makes engineering sense (e.g. because all routers in a
certain location have different paths to each of them).


	-- Niels.

--