North American Network Operators Group
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: How Not to Multihome

  • From: Justin M. Streiner
  • Date: Mon Oct 08 19:07:06 2007

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.

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.

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.

Or are you suggesting they should get PI space?

PI space, while nice, is not an option for many end users.

jms