Locating a single IPv6 or IPv4 routable prefix at multiple data centers

Question

Academic question (at the moment):

Is it possible to advertise BGP routes to a given prefix (IPv6 and/or IPv4) from multiple different physical data centers?

I guess this is multi-homing, but different. Conventional multi-homing means a single data center with multiple links. This would be multiple different geographically distributed data centers.

The desired behavior would be this: if a user in Asia accesses one of these IPs, their packets will probably end up at the Asian data center. Meanwhile if a user in the USA sends a packet to one of these IPs, their packet will instead be routed to a USA data center. And so on. Same IP, but the network should tend to route packets to the closest site.

Is this possible on the current Internet? Is it possible with IPv6, IPv4, or both? (I suspect you'd have to own your own block and advertise your own BGP routes or contract with a chain of data centers to do this...)

Answer 1

What you describe is called anycast, and common when deploying services like DNS. Because routing can change it is a bad idea for things that use longer sessions, but for short things a DNS query it is used a lot.

Answer 2

Conventional multihoming means a single network with multiple links. That network may be confined to a single datacenter, it may span the globe or anywhere in between.

Routing the same IP to multiple different servers such that each packet arrives at one of those servers is known as "anycast". This is possible either with seperate networks at each site, a single network that spans all sites or combinations of the above. The advantage of having all sites on a single network is it gives you more flexibility, on the public internet there are restrictions on the size of blocks you can advertise (for ipv4 it's a minimum of /24, for IPv6 things are more complex) while within your own network you can route individual IPs if you so desire. Having your own global network can also improve service quality even for servers you don't intend to anycast because it can put you in control of a greater proportion of the network path.

In general anycast works well for stateless UDP based request/response protocols. Protocols that establish a communications session (including anything that uses TCP) are more problematic as internet routing can change.

A soloution for this is to use anycast for the initial contact but then move to a regular unicast IP to continue the session. A common approach to doing this is to use anycast for the DNS server but not for the actual service. The downside of the DNS approach is that sometimes the DNS resolver may use different routes to the internet from the client.