iBGP RR Cluster ID - What is best practice? posted 11/24/2008
- Subject: iBGP RR Cluster ID - What is best practice?
- From: "Huan Pham" <Huan.Pham@xxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 25 Nov 2008 15:15:30 +1100
- Content-class: urn:content-classes:message
- Thread-index: AclOtHQisEKFhpF6SaSPmj5WiG+pQw==
- Thread-topic: iBGP RR Cluster ID - What is best practice?
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
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:
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: 188.8.131.52 RR in same cluster. Reflected update
*Mar 1 00:26:59.351: BGP(0): 184.108.40.206 rcv UPDATE w/ attr: nexthop
220.127.116.11, origin i, localpref 100, metric 0, originator 18.104.22.168,
clusterlist 0.0.0.45, path , community , extended community
*Mar 1 00:26:59.359: BGP(0): 22.214.171.124 rcv UPDATE about 126.96.36.199/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??