What is Anycast? One IP, Many Servers

Anycast is a network addressing method where the same IP address is announced from multiple locations simultaneously. When a client sends traffic to an anycast address, BGP routing delivers it to the nearest announcing location — "nearest" in terms of network topology, not geography, though the two often correlate.

How Anycast Works

In normal unicast routing, each IP address belongs to exactly one server at one location. In anycast, the same prefix is announced via BGP from many different locations simultaneously. Each BGP router in the world sees multiple valid paths to that prefix — one for each announcing site — and selects the best one based on standard BGP decision criteria: shortest AS path, lowest MED, local preference, and so on.

For example, 1.1.1.1 is announced by Cloudflare (AS13335) from over 300 cities worldwide. When you query 1.1.1.1, your traffic goes to whichever Cloudflare data center BGP determines is topologically closest to your network. Users in Tokyo reach a server in Tokyo; users in London reach a server in London — all using the same IP address, with no client configuration needed.

Anycast vs. Unicast, Multicast, and Broadcast

IP supports four addressing models, and anycast is the most sophisticated:

Where Anycast Is Used

• DNS root servers — all 13 root server identities (A through M) use anycast. What looks like 13 servers is actually hundreds of physical machines worldwide, all sharing those 13 addresses.
• Public DNS resolvers — 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), and 9.9.9.9 (Quad9) are all anycast. Your DNS query reaches the nearest data center automatically.
• CDNs — content delivery networks use anycast to serve static assets from the closest edge node without requiring DNS trickery for each request.
• DDoS mitigation — anycast is inherently resilient to volumetric attacks because attack traffic is spread across all announcing locations. A 1 Tbps DDoS attack directed at an anycast address is automatically distributed across dozens of sites, each absorbing only a fraction.
• NTP — pool.ntp.org uses anycast so clients connect to a nearby time server.

Anycast and TCP

Anycast works naturally with stateless protocols like DNS (UDP) where each query-response pair is independent. For TCP-based services like HTTPS, anycast requires more care. A TCP connection involves a sustained exchange of packets, and all of them must reach the same physical server. If BGP re-converges mid-session — rerouting your packets to a different anycast site — the TCP connection breaks because the new server has no record of the session.

In practice, BGP routes are stable for minutes to hours, so short-lived HTTPS connections almost never experience mid-session rerouting. Longer-lived connections (WebSocket, streaming) are more vulnerable. Operators mitigate this by:

• Using ECMP flow hashing to consistently map the same client IP+port to the same server within a site
• Combining anycast with session persistence mechanisms (sticky cookies, connection migration in QUIC)
• Designing applications so they gracefully reconnect after a failover

Anycast Routing Mechanics

To deploy anycast, the same prefix — say 1.1.1.0/24 — is announced via eBGP from multiple autonomous systems or from the same AS at multiple IXP peering points. Each BGP peer sees the announcement from its closest location and selects it as the best path.

Because each site announces the same prefix with the same AS path length (in the simplest case), the only differentiator is which paths BGP routes through — determined by peering topology and local preferences. Networks that are well-peered at many IXPs, like Cloudflare, achieve genuinely global anycast with fine-grained geographic distribution.

Anycast Failure Modes

Anycast is resilient but not immune to problems. If one site withdraws its BGP announcement — because of a fiber cut, a router failure, or a deliberate maintenance action — traffic from nearby clients is automatically rerouted to the next-closest site. This failover happens at BGP convergence speed, typically within a few seconds to a minute.

More subtly, anycast can cause asymmetric routing: a client's request might reach one site while the response travels back via a different path, which can confuse stateful firewalls or intrusion detection systems that expect to see both directions of a flow.

Viewing Anycast in the Routing Table

You can observe anycast in action using this looking glass. Anycast addresses often show routes with the same origin AS arriving via multiple different upstream paths — each representing a different physical site. Look up any major anycast address to see the convergence of AS paths:

• 1.1.1.1 — Cloudflare anycast DNS, served from 300+ cities
• 8.8.8.8 — Google anycast DNS
• 198.41.0.4 — A root nameserver (Verisign)