From: Landon Fitts (l.fitts@xxxxxxxxxxxxxx)
Date: Fri Mar 29 2002 - 20:20:33 GMT-3
I checked several sources (Parkhurst, Halabi, Caslow, Doyle 2nd edition,
cco), and with regards to synchronization with a full-meshed IBGP scenario,
it seems that you should just turn-off sync when you have a fully-meshed
IBGP topology. If you do not have a fully meshed IBGP, then you leave sync
on and redistribute from BGP to IGP.
Any time that I have configured a full-meshed IBGP, either with direct ptp
connections between IBGP peers or using a rr, I always turned off sync.
Just my 2 cents.
Regards,
Landon Fitts
CCNP, CCDP, NNCSE, NNCDE
l.fitts@mindspring.com
----- Original Message -----
From: "Peter van Oene" <pvo@usermail.com>
To: "Gregg Malcolm" <greggm@sbcglobal.net>; <ccielab@groupstudy.com>
Sent: Friday, March 29, 2002 3:53 PM
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