[99899] in North American Network Operators' Group
Re: How Not to Multihome
daemon@ATHENA.MIT.EDU (Keegan.Holley@sungard.com)
Mon Oct 8 18:44:46 2007
In-Reply-To: <3DF3B8EF-A8E5-40AD-8A8C-6A0A0C632F58@ianai.net>
To: "Patrick W. Gilmore" <patrick@ianai.net>
Cc: nanog <nanog@merit.edu>, owner-nanog@merit.edu,
"Patrick W. Gilmore" <patrick@ianai.net>
From: Keegan.Holley@sungard.com
Date: Mon, 8 Oct 2007 18:33:45 -0400
Errors-To: owner-nanog@merit.edu
This is a multipart message in MIME format.
--=_alternative 007BF1398525736E_=
Content-Type: text/plain; charset="US-ASCII"
> Also, if some network out there aggregates prefixes in an aggressive/
> odd manner, the disjoint announcement, and the reachability info it
> contains could be washed out of their routing tables, causing
> connectivity problems.
How is this different than if the customers gets their own ASN and
announces a sub-block from one of the providers?
Or are you suggesting they should get PI space?
ARIN will only hand out /22's or larger. If a client wants to multihome
with a /23 or a /24 it has to be assigned by one of hte ISP's and removed
from the aggregate.
"Patrick W. Gilmore" <patrick@ianai.net>
Sent by: owner-nanog@merit.edu
10/08/2007 06:16 PM
To
nanog <nanog@merit.edu>
cc
"Patrick W. Gilmore" <patrick@ianai.net>
Subject
Re: How Not to Multihome
On Oct 8, 2007, at 5:55 PM, Justin M. Streiner wrote:
> 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.
That is not at all guaranteed.
> 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.
If you do you have permission from the owner of the block, you Should
Not Announce it.
If the owner gives you permission and can't figure out why their
block is originated by another ASN as well, they need help. (Yes, I
realize the latter part of the last sentence is probably true for the
majority of providers, but whatever.)
In either case, your hypothetical question should not hold.
> 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.
How is this different than if the customers gets their own ASN and
announces a sub-block from one of the providers?
Or are you suggesting they should get PI space?
--
TTFN,
patrick
--=_alternative 007BF1398525736E_=
Content-Type: text/html; charset="US-ASCII"
<br><tt><font size=2>> Also, if some network out there aggregates prefixes
in an aggressive/ <br>
> odd manner, the disjoint announcement, and the reachability info it
<br>
> contains could be washed out of their routing tables, causing <br>
> connectivity problems.<br>
<br>
How is this different than if the customers gets their own ASN and <br>
announces a sub-block from one of the providers?<br>
<br>
Or are you suggesting they should get PI space?</font></tt>
<br>
<br>
<br><font size=2 face="sans-serif">ARIN will only hand out /22's or larger.
If a client wants to multihome with a /23 or a /24 it has to be assigned
by one of hte ISP's and removed from the aggregate.</font>
<br>
<br>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>"Patrick W. Gilmore"
<patrick@ianai.net></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 06:16 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">nanog <nanog@merit.edu></font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">"Patrick W. Gilmore" <patrick@ianai.net></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 Oct 8, 2007, at 5:55 PM, Justin M. Streiner wrote:<br>
> On Mon, 8 Oct 2007, Keegan.Holley@sungard.com wrote:<br>
><br>
>> I have a client that wants us to advertise an IP block assigned
by <br>
>> another<br>
>> ISP. I know that the best practice is to have them request
an AS <br>
>> number<br>
>> from ARIN and peer with us, etc. However, I cannot find
any <br>
>> information<br>
>> that states as law. Does anyone know of a document or RFC
that <br>
>> states<br>
>> 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>
That is not at all guaranteed.<br>
<br>
<br>
> Some providers take a pretty dim view of seeing chunks of their <br>
> address space show up in advertisements originating from someone <br>
> who isn't one of their customers. It can make troubleshooting
<br>
> connectivity problems for that customer (from the provider's point
<br>
> of view) very painful, i.e. "Hey, this AS, who isn't one of our
<br>
> customers, is hijacking IP space assigned to one of our <br>
> customers!" The provider could then contact your host's
upstream <br>
> (s) and ask them to drop said announcement under the impression <br>
> they're stopping someone from doing something bad.<br>
<br>
If you do you have permission from the owner of the block, you Should <br>
Not Announce it.<br>
<br>
If the owner gives you permission and can't figure out why their <br>
block is originated by another ASN as well, they need help. (Yes,
I <br>
realize the latter part of the last sentence is probably true for the <br>
majority of providers, but whatever.)<br>
<br>
In either case, your hypothetical question should not hold.<br>
<br>
<br>
> Also, if some network out there aggregates prefixes in an aggessive/
<br>
> odd manner, the disjoint announcement, and the reachability info it
<br>
> contains could be washed out of their routing tables, causing <br>
> connectivity problems.<br>
<br>
How is this different than if the customers gets their own ASN and <br>
announces a sub-block from one of the providers?<br>
<br>
Or are you suggesting they should get PI space?<br>
<br>
-- <br>
TTFN,<br>
patrick<br>
<br>
<br>
<br>
</font></tt>
<br>
--=_alternative 007BF1398525736E_=--
