Subject: BGP Route Reflection Question

From: "Reddy, Vikram" <[email-masked]>
Date: Thu, 25 Apr 2002 03:31:04 -0400

I have a couple of questions regarding BGP route reflection (RFC2796).
All the following questions pertain to non-full mesh IBGP between clients in
the same cluster.

I would appreciate if you could answer the questions.

         	           -------                            ------
	          | RR1 |-------------------------| RR2|
                       -------                            ------
                       |     |--------------     ----------|    |---------
                       |                   |     |                       |
                       |                   |     |                       |
                       ---------         ---------                   ------
	          | RRC1 |      | RRC2|                  | RR2|
                       ---------        -----------
------

RR1 and RR2 route reflectors for the cluster.
RRC1,RRC2,RRC3 : route reflector clients.
RRC1 has BGP Peering only with RR1, RRC2 has peering sessions with RR1 and
RR2, RRC3 has peering with RR2 only.

1) Is the above topology of configuring redundant RRs only for some of the
RRCs valid?

2) If you configure two RRs in a cluster for the purpose of redundancy (say
RR1 and RR2),
should RR1 treat RR2 as any other client peer(and vice-versa)?

3) If RR1 receives a route from one of its client (say RRC1) and it is the
best route, should RR1 send  
  this route to RR2?

4) If so, should RR2 accept it?  
  If RR2 accepts it, 
        should it reflect it back to its clients? 
        If it does reflect it to its client some clients which have multiple
peering sessions with the RRs (Ex RR2) will 
        get the route twice, once from RR1 and once from RR2.
       If it shouldn't reflect it, on what basis does RR2 decide that this
is a reflected route and it should not reflect it further?

Thank you,
Vikram.

---

From: "Reddy, Vikram" <[email-masked]>
Date: Thu, 25 Apr 2002 03:41:24 -0400

Sorry for the messed up diagram, I am sending it again.

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

         	           -------                              ------
	                 | RR1 |------------------------------| RR2|
                       -------                              ------
                       |     |--------------     ----------|    |---------
                       |                   |     |                       |
                       |                   |     |                       |
                       ---------           --------                   ------
           	           | RRC1   |          |  RRC2|                  |
RR2 |
                       ---------           --------                   ------

Thank you,
Vikram.

---

From: "Krishnan, Vijay G." <[email-masked]>
Date: Thu, 25 Apr 2002 12:40:12 -0400

Vikram,

Here are the answers to your question based on my understanding of the RFC.
Hope someone in the mailing list would correct me if I am wrong.

Vijay> Both the RRs should be talking (BGP peering) to all the clients. In
your diagram, if RR1 goes down, there is no peering between RR2 (redundant
RR) and RRC1.

Vijay> Whether its client or not, it should not reflect the routes from an
RR in the same cluster.

Vijay> Yes. 

Vijay> RR2 should not reflect it. It knows that it is a reflected route from
the CLUSTER_ID.

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

         	           -------                              ------

Thank you,
Vikram.

---

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
Date: Thu, 25 Apr 2002 22:29:00 +0530

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 10:10 PM
To: 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Vikram,

Vijay> Whether its client or not, it should not reflect the routes from an
RR in the same cluster.
Yes I to accetpt, But their is exceptional case where RR needs to reflect
the routes,
when it receives a route from other RR's of same cluster without cluster_id
attribute.
This situation happens when a RR1  has it's own imported route need to be
advertised to other 
internal peers (redundant RR2 & clients). In this case RR2 will re-advertise
the same route
to all clients of same cluster to maintain redundancy in the cluster.

Vijay> Yes. 

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

         	           -------                              ------

Thank you,
Vikram.

---

From: "Krishnan, Vijay G." <[email-masked]>
Date: Thu, 25 Apr 2002 14:17:48 -0400

Venu,

"This situation happens when a RR1  has it's own imported route need to be
advertised to other 
internal peers (redundant RR2 & clients). In this case RR2 will re-advertise
the same route
to all clients of same cluster to maintain redundancy in the cluster."

RR1 should always send its cluster_id when advertising routes to the members
of its cluster, even if its an imported route. Since RR1 is advertising the
route to all the clients in the cluster, why should RR2 also do the same
thing? Am I missing something.

-Vijay

-----Original Message-----
From: Venu Kumar G - CTD, Chennai. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 12:59 PM
To: Krishnan, Vijay G.; 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 10:10 PM
To: 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Vikram,

Vijay> Yes. 

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

         	           -------                              ------

Thank you,
Vikram.

---

From: "Venu Kumar G - CTD, Chennai." <[email-masked]>
Date: Fri, 26 Apr 2002 13:59:31 +0530

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 11:48 PM
To: 'Venu Kumar G - CTD, Chennai.'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Venu,

Vijay>RR1 should always send its cluster_id when advertising routes to the
members
Vijay>of its cluster, even if its an imported route. Since RR1 is
advertising the
Vijay>route to all the clients in the cluster, why should RR2 also do the
same
Vijay> thing? Am I missing something.

Venu>  All ther router in AS should be consistent while advertising routes
to external ASs and at the same time knowing all routes of other routers in
the same AS.

      If you take the above example, When RR1 advertising it's imported
route to RR2 (which is  client of RR1), Anyway you will be adding  the
ORIGINATOR_ID attribute and second thing comes CLUSTER_ID attribute adding.

       Assume the case, if your adding  your own CLUSTER_ID,then how does
the RR2 knows about RR1's imported route. He silently discards RR1 imported
routes becz he finds his own CLUSTER_ID in the path attributes. So that's
reason  I feel you should not add the CLUSTER_ID attribute to path
attributes when RR1 importing routes advertising to all other clients
(including the Redundant RR's).

     RFC 2796 also very clear on this point, you should add the cluster_Id
only when your are reflecting the route to others received from  someone
else.
"When a RR reflects a route, it must prepend the local CLUSTER_ID to
the CLUSTER_LIST."
     	However,when a route is advertising to non-clients by RR it should
treat that route as reflecting route and should  add the CLUSTER_ID even if
the route is originated or imported by the own RR.

Regards
Venu G.

        

-Vijay

-----Original Message-----
From: Venu Kumar G - CTD, Chennai. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 12:59 PM
To: Krishnan, Vijay G.; 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 10:10 PM
To: 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Vikram,

Vijay> Yes. 

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

         	           -------                              ------

Thank you,
Vikram.

---

From: "Reddy, Vikram" <[email-masked]>
Date: Fri, 26 Apr 2002 07:39:20 -0400

Hi,

I request one of the authors to clarify the point about the behaviour
of RRs in case of multiple redundant RRs in a cluster 
and remove the confusion about it.

From what I am getting from what both Venu and Vijay have written, it
looks like there is a difference in the approach they are suggesting.

What Venu seems to say is (From an earlier mail he sent to the board and
also from some mail messages he sent to me privately) :

1)If RR1 sends a route to RR2 (originated by client), RR2 should
  not accept it because of the presence of ClusterID.
2)If RR1 originates a route, it will not add its cluter ID,
  and RR2 will accept and reflect this route to its clients,
  in which case the clients will receive multiple routes 
  (having same Path Attributes but from different peers)
  and will choose one of them.
   
What Vijay seems to be saying is:
If RR1 sends a route to RR2 (originated by client or originated by RR1)
RR1 will add its cluster ID in both the cases. Further RR2
should accept this route for itself because it was sent by a client
but should  not reflect it to its clients i.e the presence of its
cluster Id in a route sent by a client does not mean a loop but
it should be taken as a reflected route and should not be reflected
further.

IMHO: 
I request one of the authors to clarify this point and remove the confusion.

I, however think what Vijay says will work correctly in all cases.
There is one thing in the method Venu suggested that does not jell.
If RR1 has an EBGP peer with X and RR2 does not, then, following Venu's
method,
RR1 will add its clutser ID and RR2 will drop it. In this case RR2 will
never 
learn the EBGP routes learnt by RR1.
Venu had earlier mentioned in an E-mail to me that RR2 must also be
configured to 
have peering with X, but it is not mandatory to have symmetry for EBGP
peers.It can
only be enforced in case of clients and IBGP peers outside the cluster.

Vikram

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 11:48 PM
To: 'Venu Kumar G - CTD, Chennai.'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Venu,

-Vijay

-----Original Message-----
From: Venu Kumar G - CTD, Chennai. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 12:59 PM
To: Krishnan, Vijay G.; 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

-----Original Message-----
From: Krishnan, Vijay G. [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 10:10 PM
To: 'Reddy, Vikram'; [email-masked]'
Subject: RE: BGP Route Reflection Question

Vikram,

Vijay> Yes. 

regards
Vijay

-----Original Message-----
From: Reddy, Vikram [mailto:[email-masked]]
Sent: Thursday, April 25, 2002 1:01 PM
To: [email-masked]'
Subject: BGP Route Reflection Question

         	           -------                              ------

Thank you,
Vikram.

---

From: Danny McPherson <[email-masked]>
Date: Fri, 26 Apr 2002 08:32:55 -0600

> 1) Is the above topology of configuring redundant RRs only for 
> some of the RRCs valid?

Yes. 

> 2) If you configure two RRs in a cluster for the purpose of 
> redundancy (say RR1 and RR2), should RR1 treat RR2 as any 
> other client peer(and vice-versa)?

No, they'd be Non-Client peers and SHOULD be configured with 
the same CLUSTER_ID value.

> 3) If RR1 receives a route from one of its client (say 
> RRC1) and it is the best route, should RR1 send this 
> route to RR2?

Yes, though it's considered a "reflected route" and should 
now contain CLUSTER_LIST/CLUSTER_ID, ORIGINATOR_ID, etc...

> 4) If so, should RR2 accept it? 

If configured with the same CLUSTER_ID, no.  If configured
with a different CLUSTER_ID, yes.

> If RR2 accepts it, should it reflect it back to its clients? 

If RR2's CLUSTER_ID isn't contained in the CLUSTER_LIST, then
yes.

> peering sessions with the RRs (Ex RR2) will get the route twice, once 
> from RR1 and once from RR2.

Indeed, hence the use of the term "redundant".

> is a reflected route and it should not reflect it further?

The CLUSTER_ID value contained in the CLUSTER_LIST.  

Also, some RR implementations don't reflect routes to routers whose 
ROUTER_ID value is equal to that of the ORIGINATOR_ID value.  
Others require that the client ignore/discard routes received from
a peer if the ORIGINATOR_ID contained in the route is equal to 
the local ROUTER_ID value.

-danny

---

From: "Reddy, Vikram" <[email-masked]>
Date: Mon, 29 Apr 2002 07:31:13 -0400

Hi Danny,

Please see my response inline..

-----Original Message-----
From: Danny McPherson [mailto:[email-masked]]
Sent: Friday, April 26, 2002 9:33 AM
To: [email-masked]'
Subject: Re: FW: BGP Route Reflection Question 

> 1) Is the above topology of configuring redundant RRs only for 

Yes. 
VIK>>
	If the configutration is valid and if some of the points you make
about reflection
	and acceptance of routes by RR2 are taken into consideration,
	then how will RRC3 recieve the routes generated by RRC1.
	Going by your algorithm
	1)RRC1 advertises its routes to RR1
	2) RR1 attaches its CLUSTER_ID and reflects the route to client and
non-client peers.
	3) Since RR2 is in the same clutser (thus has the same CLUSTER_ID as
RR1) 
	   RR2 drops the message.
	4) Since RRC3 has peering only with RR2, RRC3 does not get the
route.

This is not the desired behaviour as we would want both RR2 and RRC3 to know
about RRC1s routes.

VIK>> 
         1)If RR1 has peering with an EBGP peer X.
         2) RR1 receives a route from X. RR1 reflects the 
             route to it's client and non-client peers. Before 
             advertising, RR1 adds its CLUSTER_ID.
         3) RR2 receives the advertisement and drops it
             because of the presence of its CLUSTER_ID.
         4) RRC3 does not get the route because RR2 did not get it.

So, EBGP routes learnt by RR1 will never reach RR2 and RRC3 and clearly
this id not the desired behaviour.
        
The same argument goes for routes originated by RR2.

-danny

From the scenarios I explanied above, the method of RR2 not accepting
routes from RR1 because of the presence of the same CLUSTER_ID will not
work.

Regards,
Vikram

---

From: Danny McPherson <[email-masked]>
Date: Mon, 29 Apr 2002 08:20:36 -0600

> about reflection and acceptance of routes by RR2 are taken into 
> consideration, then how will RRC3 recieve the routes generated by 
> RRC1.
> Going by your algorithm
> RR1) RR2 drops the message.
> This is not the desired behaviour as we would want both RR2 and 
> RRC3 to know about RRC1s routes.

I'd call this a broken design.  

RRC3 would either need to be a client of RR1 or there needs to be 
peering between clients within the cluster.

>              advertising, RR1 adds its CLUSTER_ID.

Nope.  The route reflection attributes are ONLY added to 
"reflected routes".  EBGP learned and locally-sourced routes
wouldn't be considered "reflected routes".

>          4) RRC3 does not get the route because RR2 did not get it.

Nope, see above.

-danny