From: Bauer, Rick (BAUERR@xxxxxxxxxxx)
Date: Sat Mar 30 2002 - 13:43:09 GMT-3
There are three steps in correcting this problem.
1. advertise next hop in IGP
2. The router receiving the EBGP route advertises routes with itself as next
hop
3. advertise the bgp routes in IGP
For a BGP route to become synchronized you need a valid IGP route to the
next hop of the route, as Peter noted IBGP does not alter the NH of EBGP
learned routes, this where next-hop-self helps.
NHS on the router receiving the EBGP routes will assist the IBGP peers in
synchronizing the routes when sync is enabled, but only if the IGP has a
valid route to the next hop and the prefixes are in the IGP.
See Parkhurst chapters 8 & 12
-----Original Message-----
From: Peter van Oene [mailto:pvo@usermail.com]
Sent: Friday, March 29, 2002 3:53 PM
To: Gregg Malcolm; ccielab@groupstudy.com
Subject: Re: Route Reflector and Sync
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:26 GMT-3