anycasting behind different ASNs?
scg at gibbard.org
Wed Dec 6 19:56:36 UTC 2006
On Wed, 6 Dec 2006, John Kristoff wrote:
> On Wed, 06 Dec 2006 09:38:10 -0800
> matthew zeier <mrz at velvet.org> wrote:
>> Are there any practical issues with announcing the same route behind
>> different ASNs?
> This is known as Multiple Origin AS of which you should be able to
> find plenty of discussion and articles about. It's not uncommon and
> as far as I know generally doesn't cause any operational problems in
> and of itself, though doing it should be well thought out and
> understood since depending on how things fit into the routing topology,
> packets may not flow as you expect.
As others have said, the origin AS doesn't matter much, but routing
I'm assuming your goal in anycasting the service is at least in part to
speed response times. You want clients to go to the closest server.
Internet routing tends to follow financial relationships. If a network
has traffic to send somewhere, it's best to get paid for it, second best
not to have to pay, and having to pay to send it somewhere is a last
resort. Customer routes tend to have higher local preferences than peer
routes, and peer routes tend to have higher local preferences than transit
routes. When local preferences are equal, AS path length comes into play,
but in this age of "global" ASes, AS path length doesn't have much to do
For end sites in a single developed world location, this doesn't matter so
much. "Global" ASes tend to interconnect "globally" (with some
exceptions) and more local ASes tend to interconnect within their coverage
area. Hot potato routing tends to produce reasonably direct paths, no
matter which networks the traffic goes through along the way.
With anycast you have to be a bit more careful. If you get transit from
different networks in different places, you may find that your incoming
traffic is following customer relationships in undesirable ways. That is,
if your transit provider in the US is a big global network, or a customer
of a big global network, or a customer of a customer, any traffic that
hits that big global network in Europe will flow downstream into your
anycast node in the US. Meanwhile, you'll have a different set of
customer relationships pulling some of your US traffic into Europe.
An easy way around this is to be consistent about your transit and
peering arrangements across locations. If your anycast network has
transit from a network in one location, get transit from them in your
other locations, and let hot potato routing do its thing. For cases where
this isn't practical, or where you want more control over who is sending
traffic to a node, declare the node to be a "peering only" node and make
sure your peers aren't leaking the anycast routes to their out of region
More information about the NANOG