How Not to Multihome

Tue Oct 9 17:57:05 UTC 2007

On 10/8/07, Keegan.Holley at sungard.com <Keegan.Holley at sungard.com> wrote:
>
> That brings up an interesing point.  My biggest fear was that one of my
> other customers could possible be closer to me that the ISP that provides
> the primary link and it would cause them to favor the backup link because of
> AS path.  I think they are going to fight me on this and telling them to
> multihome to their original ISP would probably be frowned upon at this
> point.  I was hoping that there was an RFC for multihoming that I could use
> to bail myself out.

What they're asking to do is really Just Fine.  It may or may not accomplish
what they want, depending on how they do it, e.g. whether traffic will go
through their other ISP or yours. The main reason it's a Not Best Practice
is that it often doesn't get what the user wants, e.g. the user only has a
/29, so only the aggregate advertisement from their primary ISP works
anyway, or it's PA space so they'll still have to give it up if they change
ISPs.  But if they've got a /24, that's big enough that most carriers will
see it these days, and there's no need to clutter up the BGP ASN space if
your user doesn't need the extra flexibility.

There may even be a market for ISPs to do multihoming on a cabal basis, e.g.
Carrier X and Carrier Y get a /20 that they assign routes from to customers
that use both of them, but only advertise the aggregate to the rest of the
net.  They'd still need to handle the more specific routes internally and
exchange them across their peering link, but wouldn't have to bother the
rest of the net with that level of detail.

-- 
----
             Thanks;     Bill

Note that this isn't my regular email account - It's still experimental so
far.
And Google probably logs and indexes everything you send it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20071009/0406e7ac/attachment.html>