From: David Timmons (masterdt@yahoo.com)
Date: Thu Jul 13 2006 - 10:55:43 ART
HI,
I agree with your assessment. I think you are talking
about a case where we have two RR with the same
Cluster_ID. If so, I agree that you don't have to
worry about the RR client.
My problem is that this may not be the best design
practice. We can have better redundancy on both RR
routers if they are in different clusters. Of course,
to make this work, you must trust that the RR client
will be able to break the loop. So, maybe this is too
dangerous. In the CiscoPress, "BGP Design and
Implementation page 259," they said that IOS later
then 12.0 allows the the RR clients to understand the
Cluster attributes.
Snip from the book page 259:
Clients must understand RR attributes to prevent
potential routing information loops. This can be
accomplished by having a certain level of IOS release,
such as 12.0 or later.
Until I read this section, I always took it as a given
that you must configure the same cluster_ID's to
provide RR redundancy. By during this, each RR will
reject the routes learned from the other RR with the
same cluster_ID. So, we have taken the burden off the
RR client. Maybe we have more then one option? My
thoughts are that we can let the two RR have two+
routes to network through the ISP. If one of the RR
decides the other is a better path to the ISP, the RR
client will ignore the withdraw message. The reason is
that it will see the Originate_ID of itself.
Thanks for the response!
dt
--- Jung-I Lin <easyman.lin@gmail.com> wrote:
> 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
> >
> >
>
This archive was generated by hypermail 2.1.4 : Tue Aug 01 2006 - 07:13:47 ART