[j-nsp] BGP route-reflection question

[Guy Davies]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dmitri,

I have to say that I don't necessarily *recommend* using different cluster
IDs in the same cluster.  I merely said that it is a means to achieving what
you wanted.  I knew that Hannes specifically and possibly Juniper generally
recommends doing this but I am with Danny on this and personally recommend
using the same cluster ID and doing all iBGP from lo0 to lo0.  IMHO, using
different cluster IDs wins you little in a well structured network and can
cost you a lot (as described by Danny).

No offence intended Hannes :-)

Regards,

Guy

> -----Original Message-----
> From: Danny McPherson [mailto:danny at tcb.net]
> Sent: Thursday, May 29, 2003 1:05 AM
> To: juniper-nsp at puck.nether.net
> Subject: Re: [j-nsp] BGP route-reflection question
> 
> 
> 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
> 
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> http://puck.nether.net/mailman/listinfo/juniper-nsp
> 

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0

iQA/AwUBPtXD0o3dwu/Ss2PCEQIzPACg93FjwCb8GtOizkuL7xQTvELljlAAoOnz
op8zskvSSdSPr4kmnYuu/psn
=zl9q
-----END PGP SIGNATURE-----