On Tue, 25 Jul 2000, Howard C. Berkowitz wrote:
> >On Tue, 25 Jul 2000 [EMAIL PROTECTED] wrote:
> >
> > > I trying to add redundency to my network at work (I work for a very small
> > > local ISP) and I'd like to run BGP on this router so that if line A dies to
> > > upstream provider A, line B will take over to upstream provider B.
> > >
> > > What is the least requirement for BGP? Someone told me I needed at least a
> > > /20 of IP's from ARIN. Someone else told me that I need SWIP instead of
> > > RWHOIS. So I'm left wondering exactly what is the minimum overall
> > > requirements to run BGP?
> >
> >There is none. You can be single homed and run BGP (But why do that?).
>
> Depends on what you mean by multihomed. It can be quite reasonable
> to run BGP when you are connected to multiple POPs of a single
> provider, and want to optimize the way your provider sends you
> traffic at multiple points. See RFC1998 for this application of the
> well-known community of NO-EXPORT.
Nod. I said above "single homed" not "multi homed". What you describe
was exactly my point. UUnet does this sort of thing all the time, for
example to do ebgp multihop...
>
> In this case, if your providers do announce netblocks in a useful
> way. Useful walks the thin line between what is good for their
> customer and what is good for the global routing system.
I agree, but I would argue that the bulk of the "problem" with todays
global routing tables falls on the major backbones/NSP's and not the
individule end user/ISP (althought the burden is shared by all). An ISP
may need to inject thru multiple upstreams a /22, this may be the only way
his organization can get the redundancy they need via BGP with two
upstreams.......not much he can do about that. On the other hand you have
giants like UUnet, who insist on leaking a TON of more specific routes
into the table, from their single homed customers, even though they are
announcing aggregates. Do they know about this? yes. Do they fix
it? no. They have no operational reason for doing this, yet they do it,
while ISP "foo.com" has a true operational reason to inject a /22 or
whatever.
> >
> >Using a little tuning is needed, prepending AS and fiddiling around with
> >various knobs until you get the balance just right.
>
>
> I wouldn't call it that simple. You can prepend AS and twiddle MED,
> local pref, etc., all you want, but if, for example, your primary
> upstream doesn't advertise your more specific route and your
> secondary does, it's entirely possible that all of your outgoing
> traffic will go out the primary and return through the secondary.
This can be avoided by making a good business decision when choosing
upstreams. We have transit with UUnet, Qwest, Sprint, Frontier (Global
Crossing), Cable and Wireless........and all of them will gladly announce
even a /24 for you........I wouldn't dare go smaller though. That being
the case, it comes down to a knobs game, which IMHO can take a while, but
you can get a reasonable balance and redundancy for almost any situation.
> Internet routing has a lot of coordination aspects and isn't just
> tuning your BGP knobs,
Right, I didn't say that. BGP tuning for your typical ISP that is
multi-homed, is usually accomplished by tuning the knobs at your disposal,
and sometimes needing the upstream to do the same. I agree that
coordination is needed, in the form of some well placed phone calls to
some cluefull engineers.........for example normally you can't just change
the size of your netblock announcments if your upstream has them nailed
with an access-list........so that needs to be coordinated.......not
trying to make light of it, but choosing the right upstream is definitly
half the battle.
Brian
>
> >
> > >
> > > Maybe I don't need BGP? Maybe a floating static route might also
> >work? Please
> > > explain and give sample code if possible.
> >
> >You are paying both providers to take your traffic, so make them work for
> >their money. Run BGP and make sure all your netblocks can go across
> >either provider.
> >
> >Who are your upstreams?
>
> ___________________________________
> UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
> FAQ, list archives, and subscription info: http://www.groupstudy.com
> Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
>
--
-----------------------------------------------------
Brian Feeny, CCNA [EMAIL PROTECTED]
318-222-2638 x 109 http://www.shreve.net/~signal
Network Administrator ShreveNet Inc. (ASN 11881)
___________________________________
UPDATED Posting Guidelines: http://www.groupstudy.com/list/guide.html
FAQ, list archives, and subscription info: http://www.groupstudy.com
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
