From: Peter van Oene (pvo@xxxxxxxxxxxx)
Date: Wed Mar 13 2002 - 12:02:31 GMT-3
comments inline
At 12:31 AM 3/13/2002 -0500, Manny Gonzalez wrote:
>Have we all forgotten the reason for Sync? If the path through the IGP
>is via any NON iBGP speakers, you run the risk of black holing traffic.
>This is the reason for Sync in the first place.
>
>(AS1)---(AS2_BGP_R1--iBGP_R2--OSPF_R3--OSPF_R4--iBGP_R5)---(AS10)
>
>Now, you know you can do a iBGP peering session between R1 and R2 and
>R5. If you are ISP_AS2 and someone chooses your PATH as a transit path,
>if the OSPF routers do not have those routes to the end AS's, guess
>what? bit bucket. So then BGP needs to make sure the IGP has the routes.
this was my point.
>If you turn off sync in the above scenario, what happens? You then
>better make sure that you turn on BGP on those OSPF routers as well.
>Otherwise, all the BGP speakers should have direct connectivity to
>assure path completeness.
>If somehow my view is flawed, I welcome the corrections :-))
your take on the above is good. essentially, you full mesh, or run synch
if you wish to provide transit. in the real world, you full mesh. IGP's
cannot handle internet scale prefix entries.
>P.S. I believe IS-IS is able to handle a very large set of Internet
>routes. I also believe there is a very large backbone carrier using
>IS-IS to IGP portions of their backbone. But, these are uncorroborated
>reports.
IS-IS theoretically maxes out around ~30k, based on LSP sizes/max number of
fragments. However, in practise, this amount of prefixes might prove very
challenging for many routers to handle. IS-IS, being an IGP, in service
provider networks would only carry link and loopback addresses. Given this
topology, with some timing tweaks, many of the largest ISPs are able to run
entire networks using a single, flat IS-IS topology (ie one area/level)
There is actually more and more IS-IS info on the market. Abe Martey from
Cisco recently put out a great book on the subject, and Hannes Grendler
from Juniper has a book forthcoming and also wrote a good IS-IS chapter in
Juniper Networks: The Complete Reference. There is indeed a bunch of non
JunOS specific information in the book.
>P.P.S. I assume Cisco couldn't care less what the best practice is in a
>Lab environment. If you think that route reflectors and confederations
>with 4 routers is insane, welcome to the CCIE Lab world.
Route Reflection and Confederations are elements of best practise configs
and should be tested. BGP Synch on the other hand isn't in my opinion.
Pete
>Regards,
>
>Manny
>
>Peter van Oene wrote:
> >
> > It isn't actually possible to synchronize, nor do any transit providers. I
> > expect it's been universally disabled since 93-94 area.
> >
> > At 06:17 PM 3/12/2002 -0600, MADMAN wrote:
> > > Is it even any longer possible to synchronize, I don't think any IGP
> > >could handle the injection of 100K+ routes!! Seems like outdated
> > >attribute of BGP and should just as well be disabled by default.
> > >
> > > Dave
> > >
> > >Peter van Oene wrote:
> > > >
> > > > It is always wise to keep in mind the reasons various options exist
> in the
> > > > first place. IE, what problems where the designers trying to
> solve. Route
> > > > Reflection deals with peering in a topology that is fully meshed
> from an
> > > > IBGP perspective. Synchronization deals with route advertisement in a
> > > > topology that does not have a full IBGP mesh. Hence, these options are
> > > > designed for different networks and not likely to work well
> > > > together. Further, they shouldn't work together nor is there any sound
> > > > reason to try and make them work together.
> > > >
> > > > At 01:15 AM 3/13/2002 +0800, kenairs wrote:
> > > > >Hi ,
> > > > >So in others words, aparting from redistribute into IGP , RR will only
> > > works
> > > > >if you have turn off syn.
> > > > >Am i correct ?
> > > > >
> > > > >Or is there any other way beside redistributing to IGP ?
> > > > >
> > > > >----- Original Message -----
> > > > >From: Sandro Ciffali <sandyccie@yahoo.com>
> > > > >To: kenairs <kenairs@hotmail.com>
> > > > >Cc: <ccielab@groupstudy.com>
> > > > >Sent: Wednesday, March 13, 2002 12:38 AM
> > > > >Subject: Re: BGP RR
> > > > >
> > > > >
> > > > > > Since you have sync on, Network advertize by R2 on bgp
> > > > > > will go into R1's routing table only if it is recd.
> > > > > > both on BGP and IGP, Only then R1 will advertize that
> > > > > > network to R3.
> > > > > > If you turn off the sync on R1 then you will see it
> > > > > > being advertized to R3.
> > > > > > Or else redistribute the ethernet on R2 into your
> > > > > > igrp.
> > > > > >
> > > > > > Sandro
> > > > > > --- kenairs <kenairs@hotmail.com> wrote:
> > > > > > > Hi ,
> > > > > > > From the Cisco CD , is states the below
> > > > > > >
> > > > > > > When the route reflector receives an advertised
> > > > > > > route, depending on the
> > > > > > > neighbor, it does the following:
> > > > > > >
> > > > > > >
> > > > > > > a.. A route from an external BGP speaker is
> > > > > > > advertised to all clients and
> > > > > > > nonclient peers.
> > > > > > >
> > > > > > >
> > > > > > > b.. A route from a nonclient peer is advertised to
> > > > > > > all clients.
> > > > > > >
> > > > > > >
> > > > > > > c.. A route from a client is advertised to all
> > > > > > > clients and nonclient peers.
> > > > > > > Hence, the clients need not be fully meshed.
> > > > > > > Here is my topology,
> > > > > > >
> > > > > > > R1
> > > > > > > | |
> > > > > > > | |
> > > > > > > | |
> > > > > > > R2 R3
> > > > > > >
> > > > > > > All routers are able to reach each other through IGP
> > > > > > > ( eigrp ) . R1 is the RR
> > > > > > > R2 and R3 is the client.
> > > > > > >
> > > > > > > Now, R2 has a E0 . It then have a network command
> > > > > > > under BGP and is propagrate
> > > > > > > to R1.
> > > > > > > But R1 does not advertised the route to R3 ..
> > > > > > > Why is this so ?
> > > > > > > All routers are syn enabled.
> > > > > > >
> > > > > > >
> > > > > > > but is R2 received a route from another AS, the
> > > > > > > route will be advertised to
> > > > > > > R3.
> > > > > > >
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:57:03 GMT-3