Anycast routing is a network addressing scheme that allows multiple servers to share the same IP address, directing traffic to the server closest to the client.
Let’s see it in action. Imagine you have a global web application and want to ensure users in different continents get the fastest possible response. Instead of giving each regional server a unique IP, you assign them all the same IP address.
Here’s a simplified BGP (Border Gateway Protocol) configuration snippet for two edge routers, one in New York and one in London, both advertising the same public IP prefix 192.0.2.0/24:
New York Router (NY-RTR1):
router bgp 65001
neighbor 198.51.100.1 remote-as 65001
!
address-family ipv4 unicast
network 192.0.2.0/24
neighbor 198.51.100.1 activate
exit-address-family
London Router (LON-RTR1):
router bgp 65002
neighbor 203.0.113.1 remote-as 65002
!
address-family ipv4 unicast
network 192.0.2.0/24
neighbor 203.0.113.1 activate
exit-address-family
When a user in Paris tries to access 192.0.2.1, their local DNS resolver will return this IP. The user’s device then queries its nearest upstream router for the best path to 192.0.2.0/24. BGP, the internet’s routing protocol, will have learned about this prefix from both NY-RTR1 and LON-RTR1. The routers participating in BGP will compare the "path attributes" to determine the "best" path. In a well-configured internet, this usually means the path with the fewest hops (AS-path length) or the shortest physical distance. A router in Europe will likely see a shorter path to the London router than to the New York router, so traffic from Paris gets routed to London. A user in Los Angeles will likely see a shorter path to a server on the US West Coast (not shown here, but imagine another router advertising the same prefix) and be routed there.
The core problem anycast solves is latency and availability for globally distributed services. By making a single IP address appear to exist in multiple locations simultaneously, it allows the internet’s inherent routing intelligence to guide clients to the nearest operational instance of that service. This isn’t about load balancing in the traditional sense of distributing requests across a pool of servers behind a single IP; it’s about directing different clients to different servers based on their network proximity.
Internally, BGP is the workhorse. When multiple routers advertise the same IP prefix, BGP’s path selection algorithm kicks in. The most common criteria for selecting the "best" path include:
- AS-Path Length: The number of autonomous systems (ASes) a route traverses. Shorter paths are preferred.
- Local Preference: An administrative setting within an AS to prefer certain exit points.
- MED (Multi-Exit Discriminator): A hint to neighboring ASes about preferred paths, though often ignored.
- Origin: Routes originated within an AS are generally preferred over those learned from peers.
For anycast, you’re primarily relying on AS-Path length and the physical topology of the internet. If NY-RTR1 and LON-RTR1 are in different ASes, and a European ISP’s router sees a path to 192.0.2.0/24 via LON-RTR1 (AS 65002) with an AS-path of 65002 and via NY-RTR1 (AS 65001) with an AS-path of 65001, <some_other_AS>, it will prefer the path through LON-RTR1.
The magic is that you don’t need a central controller. The internet’s distributed nature, governed by BGP, handles the routing decisions. The key is simply to announce the same IP prefix from multiple, geographically dispersed locations.
What most people don’t realize is that anycast doesn’t inherently guarantee which server will be chosen if two locations are very close in terms of network path. While AS-path is a strong indicator, subtle BGP attributes or even the specific peering arrangements of the client’s ISP can influence the final path. Furthermore, simple IP address duplication isn’t enough; the IP prefix must be routable on the public internet and advertised via BGP from each location.
The next major challenge you’ll encounter is handling failover gracefully when one of your anycast endpoints goes offline.