Re: iBGP RR Cluster ID - What is best practice? posted 11/25/2008
- Subject: Re: iBGP RR Cluster ID - What is best practice?
- From: "Narbik Kocharians" <narbikk@xxxxxxxxx>
- Date: Mon, 24 Nov 2008 22:16:33 -0800
- Cc: ccielab@xxxxxxxxxxxxxx
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=fTFGR8PZoz/Pmmz18fdIa0sxUOMpHGCCvgfV0ZhYpAU=; b=SzAqy1e7w6Wih4NuWCT9tbr6cm5TM2tyPFxSxJldXTj1dF8DzgamknPKHIiySi+8Jp YVlLhVotoM35DJi1s16uVMnPB2uS7c1B5YfAjvPgeWPdg/Z4VLUApahaeOH/GboGOywD n8+JkZd01Yv7spS3AHe3i2aG6GPnSGxWhfNWw=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=eFanJS8YyDUQV4cMYqgnv5OE8w8JnbLKVOiYa/UuLXT7aI0WOMJpSJGonjydFZ53D/ +mCovKew4ro9QsXSzkLPNkP+SX9jAm/Q+UKEH+b/RvxQ+eeoS0t6U5IHnLlDsF2S2jhi wSYwS+j/X0ovB8BbXxAt5tE8h6aMQCYAUItFg=
- In-reply-to: <2214055616B870459CDD1EE527DC3859080F8577@sydmail.peopletelecom.com.au>
- References: <AclOtHQisEKFhpF6SaSPmj5WiG+pQw==> <2214055616B870459CDD1EE527DC3859080F8577@sydmail.peopletelecom.com.au>
Bunch of us had a good discussion regarding RRs and cluster ids, do a search
and i am sure you will find it beneficial.
On Mon, Nov 24, 2008 at 8:15 PM, Huan Pham
> 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
> 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: 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??
> Blogs and organic groups at http://www.ccie.net
> Subscription information may be found at:
CCSI#30832, CCIE# 12410 (R&S, SP, Security)
Sr. Technical Instructor