[99892] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: How Not to Multihome

daemon@ATHENA.MIT.EDU (Keegan.Holley@sungard.com)
Mon Oct 8 18:22:42 2007

In-Reply-To: <Pine.LNX.4.64.0710081744060.4258@whammy.cluebyfour.org>
To: "Justin M. Streiner" <streiner@cluebyfour.org>
Cc: nanog <nanog@merit.edu>, owner-nanog@merit.edu
From: Keegan.Holley@sungard.com
Date: Mon, 8 Oct 2007 18:14:51 -0400
Errors-To: owner-nanog@merit.edu


This is a multipart message in MIME format.
--=_alternative 007A36328525736E_=
Content-Type: text/plain; charset="US-ASCII"

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" <streiner@cluebyfour.org> 
Sent by: owner-nanog@merit.edu
10/08/2007 05:55 PM

To
Keegan.Holley@sungard.com
cc
nanog <nanog@merit.edu>
Subject
Re: How Not to Multihome







On Mon, 8 Oct 2007, Keegan.Holley@sungard.com 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




--=_alternative 007A36328525736E_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">That brings up an interesing point.
&nbsp;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. &nbsp;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. &nbsp;I was hoping that
there was an RFC for multihoming that I could use to bail myself out.</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>&quot;Justin M. Streiner&quot;
&lt;streiner@cluebyfour.org&gt;</b> </font>
<br><font size=1 face="sans-serif">Sent by: owner-nanog@merit.edu</font>
<p><font size=1 face="sans-serif">10/08/2007 05:55 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">Keegan.Holley@sungard.com</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">nanog &lt;nanog@merit.edu&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Re: How Not to Multihome</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2><br>
On Mon, 8 Oct 2007, Keegan.Holley@sungard.com wrote:<br>
<br>
&gt; I have a client that wants us to advertise an IP block assigned by
another<br>
&gt; ISP. &nbsp;I know that the best practice is to have them request an
AS number<br>
&gt; from ARIN and peer with us, etc. &nbsp;However, I cannot find any
information<br>
&gt; that states as law. &nbsp;Does anyone know of a document or RFC that
states<br>
&gt; this?<br>
<br>
It's not 'law' per se, but having the customer originate their own <br>
announcements is definitely the Right Way to go.<br>
<br>
Some providers take a pretty dim view of seeing chunks of their address
<br>
space show up in advertisements originating from someone who isn't one
of <br>
their customers. &nbsp;It can make troubleshooting connectivity problems
for <br>
that customer (from the provider's point of view) very painful, i.e. &quot;Hey,
<br>
this AS, who isn't one of our customers, is hijacking IP space assigned
to <br>
one of our customers!&quot; &nbsp;The provider could then contact your
host's <br>
upstream(s) and ask them to drop said announcement under the impression
<br>
they're stopping someone from doing something bad.<br>
<br>
Also, if some network out there aggregates prefixes in an aggessive/odd
<br>
manner, the disjoint announcement, and the reachability info it contains
<br>
could be washed out of their routing tables, causing connectivity <br>
problems.<br>
<br>
Standard caveats about the block being a /24 or larger also apply.<br>
<br>
jms<br>
<br>
<br>
</font></tt>
<br>
--=_alternative 007A36328525736E_=--


home help back first fref pref prev next nref lref last post