North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: anycasting behind different ASNs?

  • From: Steve Gibbard
  • Date: Wed Dec 06 15:18:26 2006

On Wed, 6 Dec 2006, John Kristoff wrote:

On Wed, 06 Dec 2006 09:38:10 -0800
matthew zeier <[email protected]> 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 topology does.

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 with distance.

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 upstreams.