Re: Route Reflector and Sync

From: Peter van Oene (pvo@xxxxxxxxxxxx)
Date: Fri Mar 29 2002 - 15:40:13 GMT-3


   
Cisco does not provide the ability to do NH rewrites on IBGP learned
routes. R2 has no EBGP connectivity. Further, the output presented in the
original question indicates that the route is clearly not
synchronized. I'm actually just trying to get some lab access at gettcomm
to test this scenario out and verify some hypothesis that I have.

At 12:54 PM 3/29/2002 -0500, John Elias wrote:
>Bob,
>
>Did you try next-hop-self statements on R2(RR) to its spokes and visa
>versa. The sync will only inject the route into the routing table if it
>sees a legitimate route to get to that network. If router is unable to
>reach the particular network advertised by BGP, through its IGP, it will
>not install it into the routing table.
>
>I would recommend a good reference book called "Cisco BGP-4 Command and
>Configuration Handbook" by William R. Parkhurst, Ph.D., CCIE #2969
>
>John E.
>CCIE #8150
>
>
>>From: Peter van Oene <pvo@usermail.com>
>>Reply-To: Peter van Oene <pvo@usermail.com>
>>To: "Bob Sinclair" <bsin@erols.com>, <ccielab@groupstudy.com>
>>Subject: Re: Route Reflector and Sync
>>Date: Fri, 29 Mar 2002 11:59:53 -0500
>>
>>For what its worth, if I saw this scenario on a test, I think I would get
>>up and leave.
>>
>>
>>At 09:57 PM 3/28/2002 -0500, Bob Sinclair wrote:
>>>Cisco Experts:
>>>
>>>This topic has been brought up a couple of times, but I have yet to see an
>>>answer (maybe I missed it?)
>>>
>>>R1--------R2--------R3
>>>
>>>If all are running OSPF, R3 is a RR client of R2, Sync is on, I cannot get
>>>a route injected at R3 to sync on R1. The OSPF ID and BGP ID seem to
>>>match. Is turning off sync the only answer?
>>>
>>>I believe the show commands below demonstrate OSPF and BGP see the route
>>>as from the same ID. What am I missing here?
>>>
>>>THANKS!
>>>
>>>R1-RTA#sh ip b
>>>BGP table version is 1, local router ID is 200.200.200.200
>>>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
>>>* i192.68.5.0 172.16.50.1 0 100 0 i
>>>R1-RTA#i
>>>Gateway of last resort is not set
>>>
>>> 172.16.0.0/24 is subnetted, 5 subnets
>>>C 172.16.220.0 is directly connected, TokenRing1/0
>>>O 172.16.50.0 [110/3124] via 172.16.70.2, 00:46:48, Serial0/0
>>>C 172.16.20.0 is directly connected, Serial1/0
>>>O 172.16.2.0 [110/1563] via 172.16.70.2, 00:46:48, Serial0/0
>>>C 172.16.70.0 is directly connected, Serial0/0
>>>R 192.68.10.0/24 [120/1] via 172.16.20.1, 00:00:13, Serial1/0
>>>O 192.68.5.0/24 [110/4686] via 172.16.70.2, 00:46:48, Serial0/0
>>>R1-RTA#sh ip route 192.68.5.0
>>>Routing entry for 192.68.5.0/24
>>> Known via "ospf 1", distance 110, metric 4686, type intra area
>>> Redistributing via rip
>>> Last update from 172.16.70.2 on Serial0/0, 00:46:58 ago
>>> Routing Descriptor Blocks:
>>> * 172.16.70.2, from 6.6.6.6, 00:46:58 ago, via Serial0/0
>>> Route metric is 4686, traffic share count is 1
>>>
>>>R1-RTA#sh ip b 192.68.5.0
>>>BGP routing table entry for 192.68.5.0/24, version 0
>>>Paths: (1 available, no best path)
>>> Not advertised to any peer
>>> Local
>>> 172.16.50.1 (metric 3124) from 172.16.70.2 (6.6.6.6)
>>> Origin IGP, metric 0, localpref 100, valid, internal, not
>>> synchronized
>>> Originator: 6.6.6.6, Cluster list: 172.16.2.2
>>>R1-RTA#



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:25 GMT-3