From: Bauer, Rick (BAUERR@xxxxxxxxxxx)
Date: Sat Mar 30 2002 - 12:55:26 GMT-3
But that is the point of all of this, isn't it? It is #@$%ing hard to get
this to work. The test is all about the integration of obscure difficult
stuff, so you better know how to make this work.
-----Original Message-----
From: Peter van Oene [mailto:pvo@usermail.com]
Sent: Friday, March 29, 2002 6:30 PM
To: Landon Fitts; Gregg Malcolm; ccielab@groupstudy.com
Subject: Re: Route Reflector and Sync
I agree and have posted to this effect many times. Indeed, my overall
point is that BGP Synchronization is antiquated (and has been for some
years) and really shouldn't be studied nor tested upon. Further, Route
Reflect and Synchronization are not designed for use together as
Synchronization becomes irrelevant in a full meshed environment as you
point out.
However, the question keeps popping up as folks continue to try and setup
these topologies and kludge them together.
At 06:20 PM 3/29/2002 -0500, Landon Fitts wrote:
>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