[j-nsp] BGP route-reflection question

[Hannes Gredler]

i second guys' assessment: having RRs with different cluster-IDs is the way
how we recommend setting up route reflection;

/hannes

On Wed, May 28, 2003 at 09:15:06AM +0100, Guy Davies wrote:
|  
| -----BEGIN PGP SIGNED MESSAGE-----
| Hash: SHA1
| 
| If there is a connection between RR1 and RR2 then the client will maintain
| iBGP connections to both of the RRs.  Remember, iBGP is inherently capable
| of multihop.
| 
| The other possible solution for getting RR1 to accept routes from RR2 is to
| give them both different cluster IDs.  There is no requirement for all RRs
| associated with a single "cluster" to have a common cluster ID.  Therefore,
| each RR would see the other's cluster ID in the cluster list and accept the
| prefix.  However, it would still be receiving a better path direct from the
| client (shorter cluster list) :-)
| 
| To answer your question.  Intracluster reflection is client-to-client
| reflection (i.e. routes learned by RR from client A will be reflected to
| client B) so there is no requirement for a full mesh within the cluster.  If
| you want to turn this off then you can do so with "no-client-reflect" in the
| particular group.
| 
| Regards,
| 
| Guy
| 
| > -----Original Message-----
| > From: Dmitri Kalintsev [mailto:dek at hades.uz]
| > Sent: Wednesday, May 28, 2003 8:00 AM
| > To: juniper-nsp at puck.nether.net
| > Subject: [j-nsp] BGP route-reflection question
| > 
| > 
| > Hi All,
| > 
| > Let's imagine that I have two straight ipv4 BGP route 
| > reflectors in the same
| > cluster, say R1 and RR2. Now imagine that I have a reflector 
| > client, which
| > is:
| > 
| > a) Connected to both of them via dedicated point to point links;
| > b) Advertising the same routes to both of them.
| > 
| > Now imagine that one of the point to point links (say client 
| > to RR1) has
| > failed. Client would still advertise it's routes to the RR2, 
| > and RR2 would
| > readvertise them to RR1.
| > 
| > The experience that I had with other vendor's equipment is 
| > that RR1 would
| > not accept the client route advertisements from RR2, because 
| > it would reject
| > them having seen it's own cluster ID in these. The only way 
| > to make this
| > work was to remove the cluster ID (cluster list is used 
| > instead to prevent
| > routing loops).
| > 
| > In JunOS, it is a prerequisite and the only way to configure 
| > route reflector
| > client by setting the cluster ID in the bgp group to which the client
| > belongs.
| > 
| > http://www.juniper.net/techpubs/software/junos/junos57/swconfi
| g57-routing/html/bgp-config37.html#1015846
| 
| states:
| 
| "By default, the BGP route reflector performs intracluster reflection
| because it assumes that all the client peers are not fully meshed."
| 
| Could anybody please clarify to me how this is implemented in JunOS and this
| "intracluster reflection" is?
| 
| SY,
| - -- 
| D.K.