From: Narbik Kocharians (narbikk@gmail.com)
Date: Tue Nov 25 2008 - 19:34:13 ARST
Pradeep,
As i mentioned earlier, we had a very good discussion about RRs awhile ago,
you should search and read it the posts.
But i don't know of a provider that configures the cluster-id, typically a
RR-client must be a client in at least 2 or more clusters, this way the
provider maximizes its availability.
*I totally agree with you.*
On Tue, Nov 25, 2008 at 1:19 PM, Pradeep <chanpraddy@gmail.com> wrote:
> We can't leave it off totally. The options are
> - cluster-id = router-id by default
> - cluster-id is set to something else
>
> While there are scenarios in which the cluster-id is manually set (to be
> the same on multiple RRs), the common practice is to leave it to the
> default.
>
>
> On Tue, Nov 25, 2008 at 1:16 AM, Narbik Kocharians <narbikk@gmail.com>wrote:
>
>> Huan,
>>
>> 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
>> <Huan.Pham@peopletelecom.com.au>wrote:
>>
>> > 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
>> >
>> > _______________________________________________________________________
>> > Subscription information may be found at:
>> > http://www.groupstudy.com/list/CCIELab.html
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> --
>> Narbik Kocharians
>> CCSI#30832, CCIE# 12410 (R&S, SP, Security)
>> www.MicronicsTraining
>> www.Net-Workbooks.com <http://www.net-workbooks.com/>
>> Sr. Technical Instructor
>>
>>
>> Blogs and organic groups at http://www.ccie.net
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>>
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> "Silence is the toughest argument to refute"
>
-- Narbik Kocharians CCSI#30832, CCIE# 12410 (R&S, SP, Security) www.MicronicsTraining www.Net-Workbooks.com Sr. Technical InstructorBlogs 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