North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: How Not to Multihome

  • From: Keegan . Holley
  • Date: Mon Oct 08 18:24:18 2007


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.




"Justin M. Streiner" <[email protected]>
Sent by: [email protected]

10/08/2007 05:55 PM

To
[email protected]
cc
nanog <[email protected]>
Subject
Re: How Not to Multihome






On Mon, 8 Oct 2007, [email protected] wrote:

> I have a client that wants us to advertise an IP block assigned by another
> ISP.  I know that the best practice is to have them request an AS number
> from ARIN and peer with us, etc.  However, I cannot find any information
> that states as law.  Does anyone know of a document or RFC that states
> this?

It's not 'law' per se, but having the customer originate their own
announcements is definitely the Right Way to go.

Some providers take a pretty dim view of seeing chunks of their address
space show up in advertisements originating from someone who isn't one of
their customers.  It can make troubleshooting connectivity problems for
that customer (from the provider's point of view) very painful, i.e. "Hey,
this AS, who isn't one of our customers, is hijacking IP space assigned to
one of our customers!"  The provider could then contact your host's
upstream(s) and ask them to drop said announcement under the impression
they're stopping someone from doing something bad.

Also, if some network out there aggregates prefixes in an aggessive/odd
manner, the disjoint announcement, and the reachability info it contains
could be washed out of their routing tables, causing connectivity
problems.

Standard caveats about the block being a /24 or larger also apply.

jms