From: Peter van Oene (pvo@xxxxxxxxxxxx)
Date: Fri Mar 29 2002 - 17:53:13 GMT-3
This is actually not a next hop problem. Synchronization with OSPF depends
on a comparison of BGP and OSPF RID's, not next hops.
Also, when route reflecting, the BGP Next-Hop attribute is not changed. The
RR topology is purely a logical construct that allows a more scalable
distribution of BGP routing information.
At 11:21 AM 3/29/2002 -0800, Gregg Malcolm wrote:
>Peter,
>
>Just out of my own curiosity, would a potential solution be to make R3 a RR
>also (with clusters) ? Wouldn't that force the NH to be R3 on R1 ? I'm
>still learning BGP and am likely to be for a long time at this rate, so my
>apologizes if this seems ridiculous :)
>
>Seems to me that a confed might be another solution ? (to force confed EBGP
>between R1 and R2 which would fix the NH problem)
>
>I'm sure I'm way out in left field on this one,
>
>Gregg
>----- Original Message -----
>From: "Peter van Oene" <pvo@usermail.com>
>To: <ccielab@groupstudy.com>
>Sent: Friday, March 29, 2002 10:40 AM
>Subject: Re: Route Reflector and Sync
>
>
> > 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