How One IP Address Can Exist in Hundreds of Locations Simultaneously
Every networking engineer learns early that an IP address uniquely identifies one device. That principle holds for unicast — the normal mode of IP communication where one source sends to one destination. But it breaks when you understand anycast, a routing strategy that deliberately assigns the same IP address to many different servers in many different geographic locations.
Anycast is not a violation of IP addressing rules — it exploits them. It works because routing decisions on the internet are made locally, hop by hop, based on BGP routing tables. If multiple servers in different cities all announce the same IP prefix via BGP, routers will direct each user's traffic to whichever announcement is closest in BGP metric terms — typically the geographically nearest server. The IP address appears singular, but the infrastructure behind it is massively distributed.
This technique underpins virtually every large-scale internet service that requires global performance and resilience. Google's public DNS resolver 8.8.8.8 operates through anycast — when you query it from Japan, you are reaching a server in Asia, not in the United States. Cloudflare's entire network (including 1.1.1.1) is anycast. The DNS root servers have used anycast since the early 2000s to scale from 13 logical addresses to hundreds of physical servers worldwide.
How Anycast Routing Works Technically
The mechanism is straightforward: multiple servers in different autonomous systems (or in different PoPs within the same AS) are configured with identical IP addresses or identical IP prefix blocks. Each server's upstream routers advertise that prefix to their BGP peers. BGP propagates these advertisements globally.
When a packet is destined for an anycast IP, each router along the path consults its BGP routing table and forwards the packet toward the BGP-preferred path for that prefix. Because BGP selects paths based on AS-PATH length, local preference, and other metrics that typically favor shorter paths, the packet naturally flows toward the nearest announcing server. Different users in different geographic regions will have different routing table entries for the same prefix, sending them to different physical servers.
Crucially, there is no coordination protocol between the anycast nodes. They do not know about each other. Each simply announces the same prefix and accepts whatever traffic BGP delivers to it. This decoupling is what makes anycast so operationally simple and so robust.
The BGP Anycast Advertisement Process
A practical anycast deployment works like this:
- Assign the same /24 (or specific IP within it) to servers in multiple data centers, for example in New York, London, Singapore, and São Paulo.
- Each data center's upstream ISP (or the operator's own AS, if they have one) advertises the anycast prefix to the global BGP routing table.
- BGP propagates these advertisements. Routers worldwide now have multiple paths to the same prefix, selecting the shortest/preferred one based on BGP path selection rules.
- A user in Europe queries the anycast IP. Their ISP's routers have a BGP path through a European peering point to the London server. The query arrives in London.
- A user in Asia queries the same IP. Their routers have the BGP path to Singapore. The query arrives there.
- Both users receive a response from the same IP address, but from different physical machines.
Architecture Components of an Anycast System
| Component | Role | Examples |
|---|---|---|
| Anycast nodes | Servers sharing the same IP, answering requests | DNS resolvers, CDN edge servers, NTP servers |
| BGP routing | Directs traffic to nearest announcing node | iBGP within AS, eBGP to upstream ISPs |
| Anycast prefix | The IP block announced from all locations | /24, /32, or specific address within a block |
| Upstream ISPs / IXPs | Peer and propagate BGP announcements | IX points, transit providers at each PoP |
| Health monitoring | Withdraw BGP announcement if node is unhealthy | ExaBGP, BIRD with BFD/health checks |
| Stateless application layer | Services must handle requests without session state | DNS (stateless), HTTP with shared cache |
Anycast and DDoS Mitigation
Anycast's most powerful security property is its natural resistance to volumetric DDoS attacks. In a unicast architecture, all traffic for an IP address — legitimate and malicious — converges on a single server or a small cluster. A sufficiently large attack overwhelms the target's bandwidth or processing capacity.
With anycast, a DDoS attack targeting the anycast IP is automatically distributed across all announcing nodes by the global BGP routing system. If an attacker in Europe sends 100 Gbps of traffic at the anycast IP, that traffic routes to the European node. Traffic from Asia routes to the Asian node. The attack does not aggregate at a single point — it disperses across the entire global infrastructure.
Major DDoS mitigation providers (Cloudflare, Akamai, AWS Shield Advanced) use anycast specifically for this absorption property. Their anycast networks span dozens to hundreds of PoPs globally. By announcing a customer's IP (or a proxy IP) via anycast from all these PoPs, even multi-hundred-gigabit attacks are absorbed across the distributed infrastructure rather than reaching the origin server.
One critical limitation: anycast distributes traffic based on BGP proximity, not absolute geographic distribution. If an attacker uses a botnet distributed in the same region as a single anycast node, that node absorbs a disproportionate share. This is why anycast is most effective when combined with traffic scrubbing (filtering malicious traffic at each node) rather than relying on dispersion alone.
Real-World Use Cases
DNS root servers: The 13 DNS root server IP addresses (identified as letters a through m) are served via anycast from hundreds of physical servers globally, operated by 12 organizations. What appears to be 13 servers is actually over 1,500 physical instances. Anycast allows query load to be distributed globally and makes the root system essentially immune to targeted attacks.
Public DNS resolvers: Google's 8.8.8.8 and 8.8.4.4, Cloudflare's 1.1.1.1, and OpenDNS resolvers all operate via anycast. This is why DNS queries to these addresses have very low latency from most locations worldwide — the query is typically answered by a node within the same country or region.
Content delivery networks: CDN providers use anycast (or a combination of anycast and DNS-based load balancing) to direct users to the nearest edge cache. Serving static assets from a nearby PoP rather than an origin server reduces latency and bandwidth costs.
NTP infrastructure: The public NTP pool (pool.ntp.org) uses anycast-like distributed DNS along with anycast at some tiers to distribute time synchronization requests across thousands of volunteer servers globally.
Anycast vs. Other Routing Strategies
| Strategy | Traffic Model | State Handling | Best For | Failure Behavior |
|---|---|---|---|---|
| Unicast | One source → one specific destination | Full stateful sessions | General-purpose connections | Single point of failure |
| Anycast | One source → nearest of many destinations | Must be stateless or use shared state | DNS, DDoS mitigation, CDN | BGP reconverges to next-nearest node |
| Multicast | One source → all members of a group | Group membership state | IPTV, streaming to many recipients | Depends on multicast routing convergence |
| Broadcast | One source → all on the segment | None | ARP, DHCP discovery | Scoped to L2 broadcast domain |
| DNS-based load balancing | Varies per DNS response (TTL-based) | Full stateful sessions possible | HTTP load balancing, geo-routing | TTL delays reconvergence |
Common Misconceptions
Anycast requires custom hardware or special routing protocol support
Anycast requires nothing beyond standard BGP. Any router that speaks BGP can participate in an anycast topology. There is no special protocol extension, no unique hardware requirement, and no coordination mechanism between anycast nodes. It is a configuration and operational approach, not a distinct protocol. Any organization with their own AS number and BGP peering relationships can deploy anycast for their services.
Anycast guarantees traffic is served by the physically closest server
Anycast routes to the BGP-closest server, which is not always the geographically closest server. BGP path selection is based on AS-PATH, local preference, MED, and other policy attributes — not physical distance or measured latency. In practice, BGP proximity correlates reasonably well with geographic proximity for most users, but there are systematic exceptions where policy decisions cause traffic to route suboptimally in geographic terms.
Anycast works well for all types of applications
Anycast works best for stateless or nearly stateless protocols. DNS queries are perfect — each query/response is independent, and there is no session state to maintain. Long-lived TCP sessions are more problematic: if a user's routing changes mid-session (BGP reconvergence after a failure), the TCP connection may end up arriving at a different anycast node that has no knowledge of the session. This is why anycast HTTP requires careful handling — either with shared session state, or by using anycast only at the TLS termination layer with subsequent forwarding to a stateful backend.
Anycast eliminates the need for any other DDoS mitigation
Anycast disperses volumetric attack traffic but does not filter it. Each anycast node still receives attack traffic proportional to the botnet traffic in its BGP region. Effective DDoS mitigation combines anycast dispersion with per-node traffic scrubbing, rate limiting, and application-layer filtering. Anycast alone against an attack specifically targeted at one geographic region — where the attacker's botnet is concentrated — will still stress that region's nodes.
Pro Tips
- Use ExaBGP or BIRD as a route health injector. Configure your anycast node to automatically withdraw its BGP advertisement when a local health check fails. This removes the unhealthy node from the global routing table, preventing traffic from being sent to a server that cannot process it. Without this, a crashed anycast node continues to receive traffic it drops.
- Monitor each anycast node independently with synthetic probes from multiple global vantage points. Because different users reach different nodes, a failure at one node may be invisible in aggregate metrics. Use a monitoring service that probes from multiple geographic locations to catch regional failures.
- Announce more-specific prefixes from individual PoPs for traffic engineering. If you need to attract traffic to a specific node (for maintenance evacuation or overload shifting), you can temporarily advertise a more-specific prefix (/25 or /26 vs. the /24 anycast prefix) from a specific location. BGP prefers more-specific prefixes, allowing surgical traffic redirection.
- Test BGP reconvergence behavior before relying on it for production failover. Simulate a node failure in a staging environment and measure how long it takes for traffic to reroute. BGP reconvergence time depends on timer configurations and can range from seconds to minutes depending on your peers' settings.
- For TCP-based anycast services, deploy a stateless front end. Terminate TLS at the anycast layer, then proxy the decrypted request to a centralized stateful backend over a private network. This gives you the latency benefits of anycast TLS termination without the session-state problems of anycast TCP.
- Track your anycast node's peering quality. A node with poor BGP peering — few peers, limited transit — will attract less traffic even if it is geographically well-positioned. Investment in IX (Internet Exchange) peering at each anycast PoP directly improves the fraction of global traffic that naturally routes to your infrastructure.
Anycast is one of the most powerful architectural patterns in large-scale internet infrastructure. The combination of automatic proximity-based routing, inherent DDoS dispersion, and zero-coordination failover makes it the definitive approach for global DNS, CDN edges, and DDoS scrubbing infrastructure. Check your DNS resolver latency and anycast performance here.