From: Huan Pham (Huan.Pham@peopletelecom.com.au)
Date: Tue Nov 25 2008 - 02:15:30 ARST
Hi GS,
Doc CD and mosts other sources state that Cluster is use to prevent
routing loop within an AS, when RR Client peers with more than one Route
Reflectors. I do not see this point!
I do accept that, there might be duplicate updates, resulting in
inefficient use of bandwidth and CPU, as clients potentially will
receive the same prefix from more than one Router Reflectors (RR).
Clients then might advertize the route received by one RR to other RR.
However, I cann't see where the routing loop can take place, given the
fact that within an iBGP cloud, the next hop for a prefix does not
change.
One the other hand, if we set up two Router Reflectors with the same
Cluster ID, we might remove redundancy in some cases.
Here's an example. Normally R1 peer with both RR1 and RR2. But if
there's a network problem, and peering between R1 & RR2 as well as RR1
& R2 are lost. The iBGP peering topology in this case is:
(RR1) (RR2)
R1 ----- R4 ------- R5 ------R2
In this case, RR1 sends update for any R1 networks to RR2, but RR2 will
reject it, because of the same Cluster ID. As a result of this
behaviour, both RR2 and R2 will lost connectivity to R1 subnets.
Similarly, both R1 and RR1 will lost connectivity to R2 subnets.
Here's a sample debug outputs.
RR1#debug ip bgp updates
BGP updates debugging is on for address family: IPv4 Unicast
*Mar 1 00:26:59.347: BGP: 45.0.0.5 RR in same cluster. Reflected update
dropped
*Mar 1 00:26:59.351: BGP(0): 45.0.0.5 rcv UPDATE w/ attr: nexthop
25.0.0.2, origin i, localpref 100, metric 0, originator 25.0.0.2,
clusterlist 0.0.0.45, path , community , extended community
*Mar 1 00:26:59.359: BGP(0): 45.0.0.5 rcv UPDATE about 22.22.22.0/24 --
DENIED due to: reflected from the same cluster;
My question is, what is the "best practice" with Route-Reflector ID.
Should we set it? Or leave it off totally??
Cheers,
Huan
Blogs and organic groups at http://www.ccie.net
This archive was generated by hypermail 2.1.4 : Mon Dec 01 2008 - 08:18:32 ARST