GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: iBGP RR Cluster ID - What is best practice? posted 11/25/2008
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


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@xxxxxxxxx>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@xxxxxxxxxxxxxxxxxxxx>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
> 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"