Brian <[EMAIL PROTECTED]> wrote
>
> > >
> > >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...
Good point. People new to design, in particular, should be aware LOTS
of very different things are called "multihoming." I have enlisted a
couple of colleagues to participate in finishing my expired Internet
Draft on definitions of multihoming.
>
> >
> > 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.
No argument. Failing to aggregate when practical is a major problem.
Of course, I have an idealized view that people routinely register
their routing policies, so we have a way to tell if someone actually
is multihomed via multipl providers.
>
> > >
> > >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.
Again you make a critical real-world point. Your upstream(s) must be
clueful, and you cannot unilaterally set up multihomed routing and
expect it to work. If one is doing this for the first time, it's
insane to do it without provider support. Some providers have
excellent resources to guide one through the process (waves to
Michelle Truman).
>
> > 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 bat
>tle.
>
Only half? :-)
___________________________________
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]
