1. Library
  2. Computer Networks
  3. IP Addresses
  4. Special Addresses

Updated 8 hours ago

When you type 8.8.8.8 into your DNS settings, you're not connecting to a single server. You're reaching one of hundreds of servers scattered across six continents, all sharing that exact same IP address.

How is this possible? The Internet's routing system automatically delivers your request to whichever server is closest—not geographically, but in network terms. This is anycast: one address, many destinations, automatic selection.

It's the invisible architecture behind services that must never fail: DNS root servers answering billions of queries daily, content delivery networks serving most of the web's images and videos, DDoS mitigation systems absorbing terabit-scale attacks.

The core insight

Anycast transforms the Internet's routing infrastructure into a distributed load balancer. Instead of building complex logic to decide which server handles your request, you announce the same address from everywhere and let the network figure it out.

This inverts the typical approach. Traditional load balancing requires DNS-based routing, geographic rules in application code, or client-side endpoint selection. Anycast pushes all of that into the network layer. The routing system becomes the load balancer.

How the Internet routes traffic

The Internet has four fundamentally different routing methods:

Unicast sends traffic from one sender to one receiver. This is most Internet traffic—HTTP requests, emails, video streams. One source, one destination.

Broadcast sends traffic to every device on a local network, whether they want it or not. ARP and DHCP use broadcast. It's inefficient, flooding networks with traffic most devices ignore. IPv6 eliminated it entirely.

Multicast sends traffic to a group of devices that explicitly opted in. IPTV uses multicast to send one video stream to thousands of subscribers simultaneously, rather than thousands of duplicate streams.

Anycast sends traffic to the nearest member of a group. Multiple servers announce the same IP address. The routing system picks the closest one automatically.

How anycast actually works

Anycast relies entirely on BGP—the Border Gateway Protocol that holds the Internet together. BGP allows networks to exchange routing information and determine optimal paths.

Multiple servers in different locations announce the same IP prefix to their BGP neighbors. Google announces 8.8.8.8 from data centers in Virginia, California, Tokyo, London, and dozens of other locations. These announcements propagate across the Internet as routers share information with peers.

When you send a request to 8.8.8.8, routers along the path select the best route using BGP metrics. The primary factor is AS-path length—the number of autonomous systems (distinct networks) the traffic must cross. Routers prefer shorter paths.

Your request arrives at whichever server advertises the anycast IP via the shortest network path. If that server fails, BGP withdraws the route announcement. Traffic seamlessly shifts to the next-best path within seconds. No manual intervention required.

"Nearest" doesn't mean what you think

Here's where intuition fails: "nearest" means network distance, not physical distance.

A user in Mumbai might reach a server in Singapore instead of a server in Mumbai—even though Singapore is physically farther away. Why? Because the network path to Singapore traverses fewer autonomous systems. The topologically closest server wins, not the geographically closest.

This matters because network topology doesn't follow geography. Undersea cables, peering agreements, and routing policies create a map that looks nothing like a physical map.

Where anycast powers the Internet

DNS root servers run entirely on anycast. All 13 root servers (A through M) use anycast addressing, collectively operating over 1,700 instances worldwide. When you query a root server, you're reaching one of hundreds of distributed locations.

Public DNS resolvers depend on anycast too. Google's 8.8.8.8 operates from data centers globally, handling roughly 30% of all DNS traffic. Cloudflare's 1.1.1.1 runs across 330+ cities.

Content delivery networks use anycast to route traffic to edge servers. A single anycast IP represents thousands of edge locations, automatically directing users to nearby points of presence. Cloudflare, Akamai, Amazon CloudFront, and Fastly all rely on this.

DDoS mitigation gains inherent protection from anycast. When attackers flood a single IP with traffic, anycast spreads that traffic across dozens or hundreds of servers instead of overwhelming one target.

During a November 2015 attack on DNS root servers—sustained traffic at 100 times normal load—anycast infrastructure prevented disruption. The attack distributed across multiple sites. No single point of failure, no single point of overload.

Why anycast matters

Latency reduction: Users connect to the nearest server in network terms, cutting response times from hundreds of milliseconds to tens of milliseconds.

Transparent failover: If a server or data center fails, BGP routing redirects traffic to the next-closest location within seconds. No load balancer reconfiguration, no DNS updates.

Global scale without complexity: Add new anycast nodes by deploying servers that announce the same IP. Clients need zero configuration updates.

DDoS absorption: Attack traffic distributes across the entire network rather than concentrating on one target. Terabit-scale attacks become manageable when spread across hundreds of endpoints.

The limitations

Stateful protocols: Anycast excels with stateless UDP protocols like DNS. The challenge with TCP is mid-connection routing changes. If network topology shifts during an active session, the connection might route to a different server that has no knowledge of the session state. It sends a TCP reset, breaking the connection.

For short-lived TCP connections, this rarely matters. Studies found session disruptions from instance switches in less than 0.017% of connections.

Route flapping: When multiple anycast nodes are equidistant, minor routing changes cause traffic to flip between nodes repeatedly. For long-running connections, this disrupts sessions.

Cascading failures: If one node becomes overwhelmed and withdraws its BGP announcement, traffic shifts to the next-closest node. If that node also lacks capacity, it can fail too—a domino effect.

No special address range

Unlike multicast (224.0.0.0/4) or private addresses (192.168.0.0/16), anycast has no reserved IP range. Any publicly routable address can be anycast.

The difference is purely routing configuration. Announce 8.8.8.8 from one location: unicast. Announce it from 50 locations via BGP: anycast. The IP address doesn't change. The routing behavior changes based on how many places announce it.

This makes anycast invisible at the IP layer. A packet sent to 8.8.8.8 looks identical whether it's reaching one server or one of hundreds.

The trade-off

Anycast isn't perfect. Stateful protocols remain challenging. Cascading failures are possible. Route flapping can disrupt sessions.

But for the Internet's most critical services, the trade-offs are worth it. DNS root servers can't afford single points of failure. CDNs need to route users to the nearest cache. DDoS mitigation requires distributing attack traffic.

Anycast solves all three with one mechanism: announce the same address from everywhere, let routing handle the rest.

Frequently Asked Questions About Anycast

Was this page helpful?

😔
🤨
😃
What is Anycast? • Library • Connected