How Not to Multihome

Tue Oct 9 01:32:50 UTC 2007

On Oct 8, 2007, at 6:45 PM, Justin M. Streiner wrote:
> On Mon, 8 Oct 2007, Patrick W. Gilmore wrote:
>
>>> 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.
>
> I never said it was.  My experience, both in my previous life as  
> the operator of a regional ISP and since then in other capacities  
> is that having disjoint origins for a chunk of some provider's  
> address space is basically asking for trouble, and it's the kind of  
> trouble that may ony pop up when something breaks.

I'm afraid your experience is not the same as many, many people.

There are currently ~1500 prefixes with inconsistent origin AS.   
These are trivially identifiable:

   <http://www.cymru.com/BGP/incon_asn_list.html>

Some of them are obvious mistakes (I doubt HKSuper is supposed to  
originate 4/8).  But many of them are not, and the Internet works  
just fine.

> My experience has also been that if a customer has a need to  
> multihome and is willing to invest both in the equipment and the  
> expertise to do so, then so be it.

That statement does not say anything.

>> If you do you have permission from the owner of the block, you  
>> Should Not Announce it.
>
> Agreed.
>
>> 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?
>
> In the case you described, the provider who holds the parent  
> address block should expect to see an advertisement for a chunk of  
> that block come in as part of the BGP feeds they receive from their  
> upstreams, and they need to accept traffic accordingly.  The  
> customer would need to tell the provider of their intentions to  
> multihome.  If the provider in question employs some type of  
> ingress/egress filtering, that filter would need to be updated to  
> recognize that traffic sourced from that sub-block as legitimate,  
> even if it comes in over their normal transit pipes.
>
> In the case I described, where the end user requested that a third  
> party provide transit for their PA space, without that provider  
> necessarily being aware of it is when things can break in strange  
> and spectacular ways.

I stated above that you should not announce another provider's space  
without their permission, and you specifically agreed.  Here you are  
talking about that space being announced without the owner's  
knowledge.  Make up your mind.

We both agree that announcing another provider's space without their  
consent is a Very Bad Thing.  I doubt you will find people willing to  
post here to the contrary.  If the owner _does_ know the space is  
being announced, the edge filters are no different whether it is  
originated in the second upstream's ASN or an ASN owned by the customer.

So again, I ask, how is that different?

>> Or are you suggesting they should get PI space?
>
> PI space, while nice, is not an option for many end users.

Which is why I was assuming you did not mean PI space, but wanted to  
ask in case you were going to suggest it.

-- 
TTFN,
patrick