From: Peter van Oene (pvo@xxxxxxxxxxxx)
Date: Tue Apr 30 2002 - 11:05:04 GMT-3
Insults notwithstanding, can you describe a situation where synchronization
would be effective? I'm not aware of any prefix limited transit AS's out
there and I'm quite sure you are aware the IGP's don' t handle 100k routes
very well. Cisco themselves emphatically suggest that the "feature" be
disabled in all ISP networks.
At 08:34 AM 4/30/2002 -0500, DAN DORTON wrote:
>One major point.
>
> >>>>synchronization does not exist in the real world.<<<<
>
>If you are running cisco gear it does.
>
>If you choose to use the fuctionality, or not is entirely up to you,
>however since it is on by default you must turn it off if it is
>undesirable in your situation.
>
>This means you MUST tweak synchronization in the "real world" by either
>shutting it off, or using IGP trusted routes in your interior.
>
>This is the whole point Cisco wants you to know is how/when & why to
>turn it off / leave it on & make it work in either case.
>
>But hey.... You're the expert right?
>
> >>> Peter van Oene <pvo@usermail.com> 04/29/02 04:36PM >>>
>One or two points inset.
>
>At 03:10 PM 4/29/2002 -0500, DAN DORTON wrote:
> >I usually work under the idea that if there is a route-reflector
> >invloved & I cannot turn off sync then look at using confederations.
> >
> >With a single P2P IBGP link you can get away with injecting the
> >networks into the IGP, but when route-reflectors come into play more
>&
> >more problems can arise (depending on your IGP & it's confguration).
> >
> >Rick is right in that there is no true solution for the problem he
>just
> >presented under the rules applied to it.
> >
> >(At least if you need to get the routes there via BGP. Otherwise you
> >could use NAT, policy routing, etc)
> >
> >I think what peter means is that in a real world situation a
> >configuration like this would not make any sense.
>
>correct. however, they don't make any sense in the lab either.
>
> >Although fully meshing a large IBGP scenario might be a bit out of
> >reach financially for some customers, so you might still need RR's.
>
>most isp's use hierarchies of route reflection
>
> >In any case in a "real world" situation turning off sync would be
> >entirely up to you & if you trust you locally routed domain then
>there
> >would not be a problem.
>
>synchronization does not exist in the real world.
>
>
> >The CCIE lab is designed to make damn sure that you know how/why &
>when
> >a technology works, or doesn't.
>
>yes, but lets hope the focus is on how technology is supposed to work,
>not
>how one might screw it up by implementing things in backward fashion.
>In
>my opinion, this does not lend any credibility, nor usability to the
>certification.
>
>
> >Sometimes in order to test it properly it must be presented in a
> >ridiculas fashion.
> >
> > >>> "Bauer, Rick" <BAUERR@toysrus.com> 04/29/02 01:57PM >>>
> >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:23 GMT-3