North American Network Operators Group
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Historical
Re: How Not to Multihome
- From: Patrick W. Gilmore
- Date: Mon Oct 08 21:47:53 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
|