From: Peter van Oene (pvo@xxxxxxxxxxxx)
Date: Tue Apr 30 2002 - 13:12:22 GMT-3
No problem Dan, I fully understand the stress your under ;-) Email has
always stunk at conveying emotion.
A final thought from myself on this topic given it has now likely extended
from signal to noise for most folks who, as with yourself, will have to
study this silly stuff based upon the general consensus that Cisco tests
weird stuff.
In all situations, full mesh IBGP (simulated or otherwise) is always better
than using IGP only routers for transit. The only reason not to use full
mesh IBGP when providing transit is when you absolutely have to use routers
that will not support it. Full mesh IBGP _and_ redistributing to your IGP
while using synchronization does not enhance the AS's ability to route
accurately. In fact, it does exactly the opposite by clogging up the IGP
and reducing convergence, and potentially by introducing routing loops
which are not at all unlikely to occur.
I''ll pop in some noisier thoughts below ;-)
At 10:00 AM 4/30/2002 -0500, DAN DORTON wrote:
>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.
Not entirely sure what you mean here, but if I am a company that provides
inter company transit and not necessarily internet transit, and I use BGP
as my inter company routing protocol, it would behove me to fully mesh my
BGP network. Given I likely have minimal (sub 5k) routes, I can
reasonably expect any router capable of handling this many routes in its
IGP to handle them far better in BGP. Furthermore, fully meshing my BGP
ensures that any BGP information I advertise will be fully accurate. Using
synchronization can lead to situations where ASBR A's IGP route is used to
validate ASBR B's BGP route which potentially causes inaccurate routing
information to propagate (see 1403 & successors) Finally, keeping external
information out of my IGP keeps my IGP small which should allow it to
converge faster.
>This has seems to be a popular solution nowadays for over all
>management agencies of smaller unmanaged agencies.
Small unmanaged agencies are unlikely to run BGP and more likely to
statically route default toward the inter agency transit provider.
>External routing to the internet would be configured a bit differently
>in this case of course. Particularly in a transit enviornment.
Synchronization cannot be configured in the case of Internet
transit. IS-IS simply can't handle that many prefixes, and very few (if
any) OSPF implementations and their respective hardware can handle 100+
type 5's
>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.
Whether you synchronize or not, the intra AS path used in a network is
generally routed hop by hop by the IGP toward the ASBR that advertises the
prefix into the AS. In a typical full mesh IBGP network, this destination
is represent by the BGP Next-Hop attribute for which the IGP maintains
reachability information. If you redistribute into your IGP, you will make
similar decisions and likely end up at the same ASBR.
However, this brings up an interesting problem with running a network where
both your IGP and EGP handle the same externals. In these networks, all
routers make routing individually for the same prefixes, however, your
perimeter routers use one control plane, and your interior routers
another. This inconsistency can lead to some unexpected traffic
patters. For example, what if you set local pref high on ASBR A and low
for the same prefix on ASBR B, but from ASBR C, the IGP path toward B is
shorter? In this case your traffic will route all the way to B and then go
from B to A. However, if a router exists in between A and B that likes B
better for that prefix, you have yourself a nice routing loop. With full
mesh IBGP, all your routers make external routing decisions based upon the
same criteria and thus consistent behavior can be achieved (or you at least
stand a better chance of it :)
In a properly meshed IBGP environment, mutlihomed customers will be much
better served by a lean IGP which, free of external information, can
rapidly converge around the types of failures that might lead to loss of
routing information as you describe. Duplicating your routing information
in two protocols is more likely to hinder convergence than aid it.
>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.
This is what BGP does best. Bogging it up with additional IGP dependencies
doesn't make a lot of sense.
>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.
Again, full mesh IBGP (or simulated of course) fits much better here with
no penalty.
>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 sounds like I'm a stub AS, not a transit AS in which case
synchronization is not relevant. If I am a transit AS that does not take a
full internet feed, again, full mesh IBGP with a lean IGP will serve me
much better.
>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