From: DAN DORTON (DHSTS68@xxxxxxxxxxxxxxx)
Date: Mon Apr 01 2002 - 10:55:40 GMT-3
I have come to the conculsion that BGP sync is so flaky that if you must
leave sync on & have to use a route reflector type situation then you
should just use a confederation instead.
Dan
>>> "Bauer, Rick" <BAUERR@toysrus.com> 03/30/02 09:55AM >>>
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:51 GMT-3