From: Peter van Oene (pvo@usermail.com)
Date: Tue Feb 25 2003 - 18:57:46 GMT-3
At 02:47 PM 2/25/2003 -0500, David Buechner wrote:
>To follow up to my question from yesterday:
>
>First, someone asked for relevant configuration information from R2 which
>I have included below.
>
>Second, I've gotten a couple of responses like Annu Roopa's which said:
A route reflector (or any bgp speaker for that matter) only advertises a
single best path. Hence, in this case, R6 sends only one of the two paths
received from r3 and r1 toward the southern routers in the network whereas
with a full mesh, those other routers would receive both paths
directly. Hence, the route reflector clients get a single best path from
r6 and will use it, vs being able to see the paths directly and chose their
own best path.
Route Reflection is highly used and very useful. Proper design includes
building hierarchies that will yield optimal/desired traffic flows. IGP
topologies and metrics are useful to consider in these designs as they tend
to be a popular tie breaker.
>>I think in the first case when u do IBGP full mesh all
>>the routers including R2,R5,R6 get two routes from R1
>>and R3 and then they decide the best path (*>).
>>
>>But when u are doing the RR case Router R6 gets two
>>paths as seen and decides the best path for the
>>networks.R6 will advertise only the best path to its
>>clients R2 and R5 and hence they have only 1 path the
>>best path of R6. What do u think ? Am i correct in
>>understanding ? someone care to comment.
>
>If this is true, then it seems like the Route Reflector is of much less
>use that I would otherwise believe. Cisco doc and Doyle Vol 2 (among
>other places) give me the idea that a route reflector cluster (properly
>configured) is a functional replacement for the same group of routers with
>full-mesh IBGP. So far I believe I've not gotten the "properly
>configured" part of this right yet - although if I'm mis-understanding the
>purpose of route reflectors here please tell me! Thanks to those who have
>responded so far - my apologies if I'm being dense!
>
>Below is output from my R2 as well as yesterday's note for reference.
>
>Thanks!
>
>David
>
>R2#sh ip bgp 172.16.0.0
>BGP routing table entry for 172.16.0.0/24, version 2
>Paths: (1 available, best #1, table Default-IP-Routing-Table)
> Not advertised to any peer
> 254
> 151.100.2.254 (metric 20) from 131.1.6.6 (131.1.6.6)
> Origin IGP, metric 0, localpref 100, valid, internal, best
> Originator: 131.1.3.3, Cluster list: 131.1.6.6
>
>R2#sh ip bgp
>BGP table version is 9, local router ID is 131.1.2.2
>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
>*>i172.16.0.0/24 151.100.2.254 0 100 0 254 i
>*>i172.16.1.0/24 151.100.2.254 0 100 0 254 i
>*>i172.16.2.0/24 151.100.2.254 0 100 0 254 i
>*>i172.16.3.0/24 151.100.2.254 0 100 0 254 i
>*>i172.16.4.0/24 151.100.2.254 0 100 0 254 i
>*>i172.16.5.0/24 151.100.2.254 0 100 0 254 i
>*>i172.16.6.0/24 151.100.2.254 0 100 0 254 i
>*>i172.16.7.0/24 151.100.2.254 0 100 0 254 i
>
>R2#sh running-config | begin router bgp
>router bgp 400
> no synchronization
> bgp log-neighbor-changes
> neighbor internal peer-group
> neighbor internal remote-as 400
> neighbor internal update-source Loopback0
> neighbor 131.1.6.6 peer-group internal
> no auto-summary
>!
>
>
>At 04:15 pm 2/24/2003 -0500, I wrote:
>>Hi all!
>>
>>I have a BGP route reflector issue on the following network:
>>
>>
>>--- (E1) --- R7 (AS 254) --- (E0) ---
>>| |
>>| |
>>R3 (AS 400) R1 (AS 400)
>>| |
>>| |
>>------------ R6 (AS 400) ------------
>> | \
>> | \-- R5 (AS 400)
>> |
>> R2 (AS 400)
>>
>>R7 is simulating a "backbone" router which is advertising several
>>networks to R1 and R3. If I set up a full mesh between all of the AS 400
>>routers (i.e. R1, R2, R3, R5, R6) then I get the results I would expect -
>>each router has two entries in the BGP table for each advertised
>>network. The route with the "closest" next-hop is then entered in the
>>main IP routing table (where distance to the next-hop is determined by
>>the IGP - OSPF in this case). If I try to set this up as a Route
>>Reflector cluster with all routers peering with R6 I do NOT get the
>>results I expect. Instead, what I get is that R2 and R5 only have one
>>entry for each network in their BGP table which corresponds to the "best"
>>one chosen by R6.
>>
>>Any ideas what I'm missing here? Thanks!
>>
>>David
>>
>>
>>R6#sh ip bgp 172.16.0.0
>>BGP routing table entry for 172.16.0.0/24, version 2
>>Paths: (2 available, best #2, table Default-IP-Routing-Table)
>> Advertised to non peer-group peers:
>> 131.1.1.1 131.1.2.2 131.1.5.5
>> 254, (Received from a RR-client)
>> 10.0.1.207 (metric 20) from 131.1.1.1 (150.100.35.1)
>> Origin IGP, metric 0, localpref 100, valid, internal
>> 254, (Received from a RR-client)
>> 151.100.2.254 (metric 20) from 131.1.3.3 (131.1.3.3)
>> Origin IGP, metric 0, localpref 100, valid, internal, best
>>R6#sh ip bgp
>>BGP table version is 9, local router ID is 131.1.6.6
>>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
>>* i172.16.0.0/24 10.0.1.207 0 100 0 254 i
>>*>i 151.100.2.254 0 100 0 254 i
>>* i172.16.1.0/24 10.0.1.207 0 100 0 254 i
>>*>i 151.100.2.254 0 100 0 254 i
>>* i172.16.2.0/24 10.0.1.207 0 100 0 254 i
>>*>i 151.100.2.254 0 100 0 254 i
>>* i172.16.3.0/24 10.0.1.207 0 100 0 254 i
>>*>i 151.100.2.254 0 100 0 254 i
>>* i172.16.4.0/24 10.0.1.207 0 100 0 254 i
>>*>i 151.100.2.254 0 100 0 254 i
>>* i172.16.5.0/24 10.0.1.207 0 100 0 254 i
>>*>i 151.100.2.254 0 100 0 254 i
>>* i172.16.6.0/24 10.0.1.207 0 100 0 254 i
>>*>i 151.100.2.254 0 100 0 254 i
>>* i172.16.7.0/24 10.0.1.207 0 100 0 254 i
>>*>i 151.100.2.254 0 100 0 254 i
>>R6#sh running-config
>>Building configuration...
>>
>>router bgp 400
>> no synchronization
>> bgp always-compare-med
>> bgp log-neighbor-changes
>> neighbor 131.1.1.1 remote-as 400
>> neighbor 131.1.1.1 update-source Loopback0
>> neighbor 131.1.1.1 route-reflector-client
>> neighbor 131.1.2.2 remote-as 400
>> neighbor 131.1.2.2 route-reflector-client
>> neighbor 131.1.3.3 remote-as 400
>> neighbor 131.1.3.3 update-source Loopback0
>> neighbor 131.1.3.3 route-reflector-client
>> neighbor 131.1.5.5 remote-as 400
>> neighbor 131.1.5.5 update-source Loopback0
>> neighbor 131.1.5.5 route-reflector-client
>> maximum-paths 2
>> no auto-summary
>>!
This archive was generated by hypermail 2.1.4 : Sat Mar 01 2003 - 11:06:35 GMT-3