RE: BGP OSPF sync with Route Reflecter

From: David Wolsefer (DWolsefer@xxxxxxxxxxxx)
Date: Mon Apr 29 2002 - 17:30:57 GMT-3


   
Are you restricted by the number of neighbor statements you can use? I am
wondering if you could more or less configure a full mesh by using two
neighbor statements on each router. That should remove the requirement for
sync.

Regards,

David Wolsefer, CCIE #5858

-----Original Message-----
From: Bauer, Rick
To: 'Peter van Oene'; 'ccielab@groupstudy.com'
Sent: 4/29/2002 3:56 PM
Subject: RE: BGP OSPF sync with Route Reflecter

Synchronization has every thing to do with it, in that configuration if
you
turn sync off at r2 the routes will synchronize. The point is if you
can't
do something because you are restricted by other requirements then you
have
to work around it.

Now if you set up a confederation using different as numbers so that r1
and
r2 are external peers the routes on r2 will synchronize without
disabling
sync, adding the routes to the IGP, or adding static routes.

Further more, if you add another connection to an external as the routes
will pass to that as. With the previous configuration they will not.

loop0---r1(as134)---e0---e0---r2(as134)---r7(as7)
loop1---

-----Original Message-----
From: Peter van Oene [mailto:pvo@usermail.com]
Sent: Monday, April 29, 2002 3:09 PM
To: Bauer, Rick; 'ccielab@groupstudy.com'
Subject: RE: BGP OSPF sync with Route Reflecter

In this case, I'll stick to my original point. The question is
flawed. First off, why are you trying to use an EGP for IGP
reachability? Further, synch has nothing to do with it as far as I can
tell. Synch refers to whether or not a router will advertise (read post
as
valid in the local rib and pass through adj-rib-out export type
policies) a
particular prefix to an EBGP peer. With no EBGP peers, synch is
irrelevant.

In your example, you don't have reachability because you shouldn't. The

routes don't synch because they shouldn't. I really hope the ccie lab
hasn't degenerated to this extent. This is so far backwards its beyond
comprehension.

(and I'm half way into that beer)

At 02:57 PM 4/29/2002 -0400, Bauer, Rick wrote:
>Here is the topology;
>
> loop0---r1---e0---e0---r2
> loop1---
>
>Loop0 200.200.200.1/25
>Loop1 200.200.200.129/25
>
>Here are the rules; You can not use static routes, loopback routes can
not
>appear in the IGP!, and you can not disable sync.
>
>Now with IBGP will the routes sync on r2? No.
>
>r4#sho ip bgp 200.200.200.0
>BGP routing table entry for 200.200.200.0/25, version 0
>Paths: (1 available, no best path)
> Not advertised to any peer
> Local
> 172.16.13.1 (metric 1323) from 172.16.13.1 (200.200.200.129)
> Origin IGP, metric 0, localpref 100, valid, internal, not
synchronized
>r4#sho ip bgp 200.200.200.128
>BGP routing table entry for 200.200.200.128/25, version 0
>Paths: (1 available, no best path)
> Not advertised to any peer
> Local
> 172.16.13.1 (metric 1323) from 172.16.13.1 (200.200.200.129)
> Origin IGP, metric 0, localpref 100, valid, internal, not
synchronized
>
>The best way to work around this is to use a confederation so that the
as
>are external.
>
>Now go drink a beer.
>
>-----Original Message-----
>From: Peter van Oene [mailto:pvo@usermail.com]
>Sent: Monday, April 29, 2002 2:39 PM
>To: Bauer, Rick; 'ccielab@groupstudy.com'
>Subject: RE: BGP OSPF sync with Route Reflecter
>
>
>Why would the routes not be in the IGP if you were using Synch? Synch
is
>designed to support IGP based transit for BGP networks. Are you
getting
>around this by eliminating the IBGP? This answer seems unrelated to
the
>usual question which is how to make synch work with route
>reflection. Maybe that wasn't the question in this case and I missed
>it. I'm not sure I understand the p2p reference either. I should
likely
>get drunk before reading this list as its getting pretty wacky these
days.
>
>Pete
>
>
>
>At 02:25 PM 4/29/2002 -0400, Bauer, Rick wrote:
> >Except for the fact that synchronization is enabled, the routes are
not
in
> >IGP, and you can't use statics. Full mesh IBGP won't help because you
need
> >EBGP to relieve the sync issue. You can suffer from the same sync
issues
on
> >a p2p link where there are no sub-optimal routing issues. I am not
> >recommending to use this in the real world. What I am suggesting is
that
> >people understand how bgp works and how to make it work with certain
> >restrictions.
> >
> >-----Original Message-----
> >From: Peter van Oene [mailto:pvo@usermail.com]
> >Sent: Monday, April 29, 2002 2:14 PM
> >To: Bauer, Rick; 'ccielab@groupstudy.com'
> >Subject: RE: BGP OSPF sync with Route Reflecter
> >
> >
> >Well, first off, a routed network where each router is a confederate
sub-as
> >would deliver lots of sub-optimal routing. Further, reconfiguring
one's
> >network into such a kludge simply to make an antiquated feature work
is
> >really not something I'd advise.
> >
> >I would much rather full mesh my IBGP than confederate in this ugly
case.
> >
> >Pete
> >
> >
> >At 02:09 PM 4/29/2002 -0400, Bauer, Rick wrote:
> > >Why is that?
> > >
> > >-----Original Message-----
> > >From: Peter van Oene [mailto:pvo@usermail.com]
> > >Sent: Monday, April 29, 2002 1:29 PM
> > >To: ccielab@groupstudy.com
> > >Subject: RE: BGP OSPF sync with Route Reflecter
> > >
> > >
> > >if this is the solution, I would suggest that the question is
seriously
> > >flawed.
> > >
> > >At 08:58 AM 4/29/2002 -0400, Bauer, Rick wrote:
> > > >Actually, a confederation is the way to work around the sync
issue,
if
> >you
> > > >can not disable sync, or put the routes in the igp, or add
statics to
>the
> > > >ibgp peer receiving the routes. HTH....
> > > >
> > > >-----Original Message-----
> > > >From: Joe Higgins [mailto:netsat@optonline.net]
> > > >Sent: Sunday, April 28, 2002 9:03 AM
> > > >To: Michael Jia
> > > >Cc: ccielab@groupstudy.com
> > > >Subject: Re: BGP OSPF sync with Route Reflecter
> > > >
> > > >
> > > >This scenario of bgp and ospf over a route reflector setup in
absolute
> > >terms
> > > >cannot work because of the inherent design of ospf and bgp.
Previous
> >posts
> > > >explain why this is so. I suggest that if one finds oneself in a
> >situation
> > > >where they find it impossible to put in the "no synchronization"
>command
> > > >then
> > > >they should start thinking outside the "BOX" and possible peer
the
> >route
> > > >reflector clients with each other, or run igrp or eigrp on top of
ospf
>on
> > > >the
> > > >route reflector portion of their network. This horse has been
beaten
up
> > > >pretty
> > > >badly. Good luck.
> > > >Joe H.
> > > >
> > > >Michael Jia wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I have a general question regarding BGP and OSPF sync when
router
> > > >reflector
> > > > > is
> > > > > used. I've seen some threads discuss it before on the list.
> > > > >
> > > > > The scenerio is like :
> > > > >
> > > > > R1 ---- R2------ R3
> > > > >
> > > > > All R1, R2, R3 are in same AS, R1 and R3 peer to external AS.
> > > > > R2 is the route reflecter with iBGP peered to both R1 and R3.
> > > > > R1 and R3 doesn't peer with each other.
> > > > > OSPF is used as IGP for R1, R2 and R3.
> > > > >
> > > > > When a eBGP route is redistritued at R1 into OSPF. The route's
> > > > > BGP id is R1, its OSPF id is also R1.
> > > > > iBGP syncs at R2 without question.
> > > > >
> > > > > However, it doesn't sync at R3. Because from R3, it sees iBGP
id
as
> >R2,
> > > > > the Reflector's ID, but OSPF id is still R1. (Am I right?
please
> >correct
> > > >me
> > > > > if my logic is wrong. At a live lab, if R3 peer with R1 , the
route
> >will
> > > > > sync
> > > > > immediatly. In R3's routing table, it clearly has the route
and
the
> >next
> > > >hop
> > > > > route as OSPF routes. )
> > > > >
> > > > > The question is, how to make it sync without using "no sync"
at
R3?
> > > > >
> > > > > Thanks a lot.
> > > > >
> > > > > Michael
> > > > >



This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:58:22 GMT-3