From: DAN DORTON (DHSTS68@xxxxxxxxxxxxxxx)
Date: Tue Apr 30 2002 - 12:00:45 GMT-3
My apologies on the insult, I really shouldn't have written that.
Bad day, close to lab date, etc etc, but again no excuse for that.
I would say if you are using BGP to internally manage customers
internal routing systems that you have have no control over, but do
control route distribution between them.
This has seems to be a popular solution nowadays for over all
management agencies of smaller unmanaged agencies.
External routing to the internet would be configured a bit differently
in this case of course. Particularly in a transit enviornment.
If you had multiple paths between your customers & wanted to insure
service even though someone managing their own routing domain somewhere
in the middle just happened to wipe out a configuration you might use
synchronization.
If the IGP's lose the routes then BGP will no longer trust them & send
the routes over a different trusted path & not blackhole the traffic
somewhere in the middle of the network that you have no control over.
You don't have any control over the IGPs, but you do have control over
the way you connect them & the traffic flows between the AS's.
Could also be a possibility of a smaller downstream ISP that might be
balancing BGP between a couple of large orginizations routing domains &
transiting traffic between them over multiple links.
If you were only taking partial internet route with default, or
aggregate routes to cover the rest of the world this might be a feasible
situation.
This way if one site dies the traffic will not be blackholed to the
entire AS, but will instead take the long way around, or the trusted
path.
>>> Peter van Oene <pvo@usermail.com> 04/30/02 09:05AM >>>
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