From: Jung-I Lin (easyman.lin@gmail.com)
Date: Thu Jul 13 2006 - 05:10:59 ART
Hi, David
From Doyle's book
"CLUSTER_LIST is an optional, nontransitive attribute that tracks
cluster IDs the same way that the AS_PATH attribute tracks AS numbers.
When an RR reflects a route from a client to a nonclient, it appends
its cluster ID to the CLUSTER_LIST. If the CLUSTER_LIST is empty, the
RR creates one. When an RR receives an update, it checks the
CLUSTER_LIST. If it sees its own cluster ID in the list, it knows that
a routing loop has occurred and ignores the update."
Back to your scenario, when the RR-Clients received routes from ISP's
Router, it send the routes which is learned from ISP to both RRx and
RRy.
For RRx's perspective, RRy is a nonclient to itself, so it will
append/create the CLUSTER_LIST and put the CLUSTER_ID in the LIST,
then RRy will ignore the updates because of the CLUSTER_ID contained
in the CLUSTER_LIST.
For RRy, the same conditon as RRx.
CLUSTER_LIST help you prevent the loops before the ORIGINATER_ID.
I'm currently awy from my lab devices, so this is only the theoretical
inference, I might be wrong.
Any comments are appreciated.
Regards,
Jung-I
On 7/13/06, David Timmons <masterdt@yahoo.com> wrote:
> Hi,
>
> Have been thinking about BGP clusters and wonder about
> Router Reflectors (RR) and the redundancy issues. I
> noticed that IOS RR clients later then 12.0 can
> understand two major attributes: originator_ID and
> cluster_list. So, so you can get the client to help
> prevent loops rather then using the cluster_ID.
>
> (RR x)--
> | <IBGP AS 1>--(RR Client)--<AS 1 to As 2>-ISP
> (RR y)--
>
> For example, if a route is injected into bgp AS 2 via
> an ISP router and arrives at our RR client, then it
> gets advertised to both RR routers. The result will be
> that the RR could have two routes to the ISP. If
> router x prefers path to router y, x will withdraw
> route sent to router y. X will also send an update to
> the RR Client; however, the RR client will not allow
> the update because the originate_id was set to the RR
> client.
>
> So, I don't understand why we would prevent routing
> loops with RR redundant designs by setting the
> cluster_ID. From some of the examples that I have been
> working on, it appears that that it is better to
> configure distinct cluster_ID's on the RR.
>
> dt
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
>
--
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:47 ART