[j-nsp] BGP route-reflection question

[Dmitri Kalintsev]

Hmm, this has turned out to be a somewhat hotter-than-anticipated
discussion, so I went to the source, as any good Luke would. The RFC2796
says:

   "In a simple configuration the backbone could be divided into many
   clusters. Each RR would be configured with other RRs as Non-Client peers
   (thus all the RRs will be fully meshed.). The Clients will be configured
   to maintain IBGP session only with the RR in their cluster. Due to route
   reflection, all the IBGP speakers will receive reflected routing
   information."

So, having a client talking to two RRs in different clusters contradicts
this RFC. We're back to the square one.

What I want to say is that in an ideal world I would have appreciated the
ability NOT to set the cluster ID, reverting back to the originator-id loop
detection mechanism. I think that the network designer should be given the
right to choose his own poison, and feel that the way Juniper's config
imposes the use of cluster-ids when configuring an RR client is a weeny bit
pushy. ;^P

Just my 2c.
--
D.K.

On Thu, May 29, 2003 at 09:25:48AM +0100, Guy Davies wrote:
>  
> -----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
---end quoted text---