anycasting behind different ASNs?

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

-Steve