From: David Timmons (masterdt@yahoo.com)
Date: Thu Jul 13 2006 - 16:15:07 ART
Hi,
I thought I would start on my understanding on the use
of the originating_ID, and cluster list. I setup the
BGP a little differently then described in my original
mail. Each router, R2, R3, and R4 are RR's and RR
clients of each other. The ISP injects a route
5.5.5.0/24 into R4. What I noticed is that R4 neither
adds a Cluster_list nor Originate_ID. This makes me
think that it is just a basic Ibgp peer. When R3 gets
the route, it will add its cluster_ID and R4 as the
Originate_ID and send it to R2. At R2, because of the
weight, will prefer the route to R3. I have seen R3
withdraw route to R4; however, I have never seen R4
get a message about a route denial as a result of the
same originate_id being in the update. Once the routes
settle down:
R3: has two routes 1)from R3 & preferred 2) one from
R4
R2: has one route to through R4
R4:one route from R5
I have not been able to create a loop using different
cluster_ID's on three routers.
Config & shows:
################ ISP/R5 ########################
router bgp 5
no synchronization
bgp log-neighbor-changes
network 5.5.5.0 mask 255.255.255.0
neighbor 192.168.1.104 remote-as 2
no auto-summary
##################################
####################R4###############
router bgp 2
no synchronization
bgp cluster-id 4.4.4.4
bgp log-neighbor-changes
network 4.0.0.0
neighbor 192.168.1.102 remote-as 2
neighbor 192.168.1.102 route-reflector-client
neighbor 192.168.1.102 password loser
neighbor 192.168.1.103 remote-as 2
neighbor 192.168.1.103 route-reflector-client
neighbor 192.168.1.105 remote-as 5
no auto-summary
########################R3###############
router bgp 2
no synchronization
bgp cluster-id 3.3.3.3
bgp log-neighbor-changes
network 3.3.1.0 mask 255.255.255.0
neighbor 192.168.1.102 remote-as 2
neighbor 192.168.1.102 route-reflector-client
neighbor 192.168.1.104 remote-as 2
neighbor 192.168.1.104 route-reflector-client
16w6d: %SYS-5-CONFIG_I: Configured from console by
consoleh ip bgp
BGP table version is 7, local router ID is 3.3.3.1
Status codes: s suppressed, d damped, h history, *
valid, > best, i -
internal
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf
Weight Path
*> 3.3.1.0/24 0.0.0.0 0
32768 i
* i3.3.3.0/24 192.168.1.102 0 100
0 i
*>i 192.168.1.102 0 100
0 i
*>i4.0.0.0 192.168.1.104 0 100
0 i
*>i5.5.5.0/24 192.168.1.105 0 100
0 5
R3#sh ip bgp 5.5.5.0
BGP routing table entry for 5.5.5.0/24, version 7
Paths: (1 available, best #1, table
Default-IP-Routing-Table)
Advertised to non peer-group peers:
192.168.1.102
5, (Received from a RR-client)
192.168.1.105 from 192.168.1.104 (192.168.1.104)
Origin IGP, metric 0, localpref 100, valid,
internal, best
#######################R2#################
router bgp 2
no synchronization
bgp cluster-id 2.2.2.2
bgp log-neighbor-changes
network 3.3.3.0 mask 255.255.255.0
neighbor 192.168.1.103 remote-as 2
neighbor 192.168.1.103 route-reflector-client
neighbor 192.168.1.103 route-map weight in
neighbor 192.168.1.104 remote-as 2
neighbor 192.168.1.104 route-reflector-client
neighbor 192.168.1.104 password loser
no auto-summary
R2#sh ip bgp
BGP table version is 19, local router ID is 172.16.1.1
Status codes: s suppressed, d damped, h history, *
valid, > best, i -
internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf
Weight Path
* i3.3.1.0/24 192.168.1.103 0 100
0 i
*>i 192.168.1.103 0 100
1000 i
*> 3.3.3.0/24 0.0.0.0 0
32768 i
*>i4.0.0.0 192.168.1.104 0 100
1000 i
* i 192.168.1.104 0 100
0 i
*>i5.5.5.0/24 192.168.1.105 0 100
1000 5 i
* i 192.168.1.105 0 100
0 5 i
R2#sh ip bgp 5.5.5.5
BGP routing table entry for 5.5.5.0/24, version 19
Paths: (2 available, best #1, table
Default-IP-Routing-Table)
Not advertised to any peer
5, (Received from a RR-client)
192.168.1.105 from 192.168.1.103 (3.3.3.1)
Origin IGP, metric 0, localpref 100, weight
1000, valid,
internal, best
Originator: 192.168.1.104, Cluster list: 3.3.3.3
5, (Received from a RR-client)
192.168.1.105 from 192.168.1.104 (192.168.1.104)
Origin IGP, metric 0, localpref 100, valid,
internal
R2#=
--- 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