Loading learning content...
When you type 8.8.8.8 to use Google's DNS service, you might assume you're connecting to a single server. But here's the reality: there is no single 8.8.8.8. That IP address is simultaneously announced from data centers in dozens of cities worldwide. When you send a packet to 8.8.8.8, the Internet's routing infrastructure automatically delivers it to the nearest instance—whether that's in Tokyo, Frankfurt, São Paulo, or Mumbai.
This is anycast delivery—a powerful technique where the same IP address is assigned to multiple servers distributed across the globe, and the network's routing protocols determine which instance receives each packet based on network proximity.
Anycast inverts the fundamental assumption of IP addressing: instead of one address identifying one interface, one address identifies a service that exists at multiple locations. The result is automatic geographic load distribution, improved resiliency, and reduced latency—all without any client-side modifications.
By the end of this page, you will understand: (1) The definition and mechanics of anycast delivery, (2) How anycast differs from unicast, broadcast, and multicast, (3) The role of BGP in enabling anycast routing, (4) Critical services that depend on anycast (DNS, CDNs), (5) The advantages and limitations of anycast, and (6) Real-world implementation considerations.
Anycast delivery is the process of sending a packet to a single IP address that is advertised from multiple locations, with the network delivering the packet to the topologically closest instance. Unlike unicast (one-to-one) or multicast (one-to-many), anycast is one-to-one-of-many: the sender addresses one destination, but that destination exists in many places.
The term 'anycast' combines 'any' (any one of several options) with 'cast' (to send), capturing the idea that the packet can reach ANY of the servers advertising that address—typically the nearest one.
From the routing system's perspective, anycast works because routing protocols don't know (or care) that the same prefix is originated from multiple places. Each anycast node announces the same IP prefix (e.g., 8.8.8.0/24) via BGP. When routers in the network receive these announcements from multiple sources, they select the 'best' route based on standard path selection—which, in most cases, means the closest origin.
| Characteristic | Description | Implication |
|---|---|---|
| Source Count | One sender | Standard client behavior |
| Destination Count | One of many servers | Network selects the instance |
| Address Type | Regular unicast address | No special address space required |
| Selection | Topologically nearest | Based on routing metrics, not geography |
| Persistence | No connection affinity | Different packets may reach different servers |
| State | Stateless protocols work best | UDP ideal; TCP requires care |
Anycast delivers to the topologically nearest server, not the geographically nearest. In most cases, these align. But if your ISP has unusual peering arrangements, packets might travel to a farther anycast node if the network path is 'shorter' in terms of AS hops or policy preferences. This is why CDN performance testing matters—your closest server depends on YOUR network's routing.
Anycast leverages the Internet's existing routing infrastructure for load balancing. Instead of:
Anycast uses the routing system itself. Every router's best-path selection automatically directs traffic toward the nearest node. This is distributed load balancing at global scale with zero configuration at intermediate routers.
Understanding anycast requires understanding BGP (Border Gateway Protocol), the routing protocol that glues the Internet together. Anycast exploits BGP's normal behavior—it's not a special mode or extension.
Anycast Network Setup Example══════════════════════════════ Service: Global DNS at 198.51.100.1/24 (anycast prefix) Deployment: Three anycast nodes in different cities ┌─────────────────────────────────────────────┐ │ Internet Routing System │ └─────────────────────────────────────────────┘ ▲ ▲ ▲ │ │ │ BGP: "I have │ │ │ BGP: "I have 198.51.100.0/24" │ │ │ 198.51.100.0/24" │ │ │ ┌──────┴──────┐ ┌────┴────┐ ┌──────┴──────┐ │ Node A │ │ Node B │ │ Node C │ │ Tokyo │ │ London │ │ New York │ │198.51.100.1 │ │198.51.100.1│ │198.51.100.1│ └─────────────┘ └─────────┘ └─────────────┘ │ │ │ │ │ │ All three nodes configure the SAME IP: 198.51.100.1 All three announce the SAME prefix via BGP Result: • Client in Japan → Routes to Tokyo node (shortest AS path) • Client in Germany → Routes to London node • Client in Brazil → Routes to New York node (likely closest) Each router on the Internet has a routing table entry for 198.51.100.0/24pointing to its locally optimal next-hop.When BGP routers receive the same prefix from multiple sources, they apply the BGP best path selection algorithm. The simplified version:
For most anycast deployments, AS_PATH length is the primary differentiator. An anycast node in your ISP's network (or a nearby peer) will have a very short AS path compared to a node across oceans. This is why anycast naturally gravitates traffic toward nearby nodes without any special configuration.
Anycast works in both IPv4 and IPv6, but their approaches differ significantly. IPv4 anycast is an operational practice, while IPv6 formally defines anycast as an address type.
IPv4 Anycast: Emergent Behavior═════════════════════════════════ • No special address format — uses regular unicast addresses• No protocol support — achieved purely through routing• Operator responsibility — must coordinate address assignment• Routing announces same prefix from multiple origins• Works because routers don't validate address uniqueness Implementation: 1. Obtain IP prefix (e.g., from RIR or IP transit provider) 2. Deploy servers in multiple locations with same prefix 3. Configure each server with same IP address on loopback 4. Announce prefix via BGP from each location 5. Traffic automatically flows to nearest node Examples of IPv4 Anycast Services: • 8.8.8.8, 8.8.4.4 (Google Public DNS) • 1.1.1.1 (Cloudflare DNS) • 9.9.9.9 (Quad9 DNS) • DNS root servers (most are anycast) • Many CDN edge serversIPv6 formally recognizes anycast as an address type but takes a pragmatic approach: syntactically, anycast addresses are indistinguishable from unicast addresses. The difference is purely operational—an address is anycast when it's assigned to multiple interfaces on different nodes.
| Aspect | IPv4 Anycast | IPv6 Anycast |
|---|---|---|
| Definition | Operational practice | Formally defined address type |
| Address Format | Regular unicast address | Unicast address assigned to multiple interfaces |
| Identification | Cannot be distinguished from unicast | Cannot be distinguished from unicast |
| Reserved Anycast | None defined | Subnet-Router Anycast (suffix ::) defined |
| Source Address Use | Should not use as source | Must not use as source (RFC 4291) |
| Deployment | BGP-based, any address | BGP-based, any address |
IPv6 Subnet-Router Anycast Address════════════════════════════════════ IPv6 defines a required anycast address for every subnet: The address with all zeros in the interface identifier portion. Example for subnet 2001:db8:1234:5600::/64: Subnet-Router Anycast: 2001:db8:1234:5600:: └────────────────────┘└─────────────────┘ 64-bit prefix 64-bit all zeros Purpose: • Reaches any router on that subnet • Useful for reaching "a router" without knowing which one • Automatically configured on all routers for their subnets Other common IPv6 anycast uses: • Mobile IPv6 home agents • 6to4 relay routers (192.88.99.1, deprecated but illustrative) • DNS resolvers (same pattern as IPv4)Because anycast addresses identify multiple interfaces, using them as the SOURCE address would cause reply packets to route to a different node than the original sender. RFCs prohibit using anycast as source address. All anycast servers must have a separate unicast address for sourcing responses—typically from a non-anycast service address or the server's management address.
Anycast has become essential infrastructure for some of the Internet's most critical services. Let's examine the applications that depend on it.
The Domain Name System is the poster child for anycast. Both the DNS root servers and major public resolvers use anycast extensively.
DNS Root Server Anycast Deployment════════════════════════════════════ The 13 DNS root server "letters" (A through M) serve billions of queries daily.But there are NOT just 13 servers—each letter is anycast to many locations. As of 2024 (approximate): A (Verisign) - 10+ anycast instances B (USC-ISI) - 3+ instances C (Cogent) - 8+ instances D (UMD) - 115+ instances E (NASA) - 255+ instances F (ISC) - 250+ instances G (DISA) - 6 instances H (ARL) - 2 instances I (Netnod) - 70+ instances J (Verisign) - 184+ instances K (RIPE NCC) - 75+ instances L (ICANN) - 200+ instances M (WIDE) - 6 instances Total: ~1,000+ actual root DNS servers, reachable via 13 anycast addresses. Benefits: • Resilience: DDoS attack on one instance doesn't affect others • Performance: Queries answered by nearby instances • Scalability: Add capacity by deploying more instances Example: When you query a.root-servers.net (198.41.0.4): • Your ISP's resolver sends query • Internet routing delivers to nearest "A" instance • Could be in your country or continent • Response returns directly via unicastA 100 Gbps DDoS attack against a single server is catastrophic. But against an anycast service with 50 global locations, each instance receives only ~2 Gbps—potentially absorbable. Anycast doesn't stop attacks, but it transforms concentrated attacks into distributed ones, buying time and capacity for mitigation.
Anycast works naturally with stateless, request-response protocols like DNS (over UDP). But TCP requires special consideration because connections are stateful, and anycast routing can change mid-connection.
TCP Connection Broken by Route Change═══════════════════════════════════════ Time 0: Client connects to anycast address 192.0.2.1 → Routes to Server A (New York) → TCP handshake completes with Server A Client ←───────────────→ Server A (NY) TCP connection established Time 5: BGP route flap occurs (link failure, policy change, etc.) → Client's path now points to Server B (London) Time 6: Client sends TCP data packet → Routes to Server B (London) → Server B has no knowledge of this TCP connection → Server B sends TCP RST → Connection breaks! Client ───────────────→ Server B (London) "I'm sending you data..." "I don't know you! RST!" The TCP connection state exists only on Server A,but packets are now routed to Server B. This is called "TCP anycast affinity loss."QUIC (HTTP/3) includes built-in connection migration. Instead of identifying connections by IP/port 5-tuple (which fails when anycast routes change), QUIC uses a connection ID that survives path changes. This makes QUIC over anycast much more robust than TCP over anycast—a significant architectural advantage for CDNs.
Despite the theoretical concerns, Cloudflare and other major CDNs successfully run millions of TCP connections over anycast. How?
Anycast offers compelling advantages for specific use cases but comes with inherent limitations. Understanding both is crucial for proper deployment.
| Use Case | Anycast Suitability | Why |
|---|---|---|
| DNS Resolution | Excellent | Stateless UDP; short queries; latency-sensitive |
| CDN Edge Serving | Good | Short HTTP connections; QUIC adoption helps; failover valuable |
| API Services | Moderate | Works well with short connections; consider QUIC |
| Database Connections | Poor | Long-lived, stateful connections; route changes break connections |
| WebSocket Apps | Poor | Persistent connections; state tied to specific server |
| Streaming Media | Varies | Initial connection via anycast OK; stream itself often unicast |
Many services use a hybrid: anycast for discovery, unicast for service. The initial connection to an anycast address returns the unicast address of the optimal server, and subsequent traffic uses that unicast address directly. This combines anycast's discovery benefits with unicast's connection stability.
Deploying anycast requires careful planning. Here are the key considerations for a successful implementation.
Anycast Node Configuration (Conceptual)═════════════════════════════════════════ Each Anycast node configures: 1. LOOPBACK INTERFACE with anycast IP: interface loopback0 ip address 192.0.2.1/32 # Anycast address 2. BGP ANNOUNCEMENT of the anycast prefix: router bgp 65001 neighbor 203.0.113.1 remote-as 65002 # Upstream ISP network 192.0.2.0/24 # Anycast prefix # Stability: don't withdraw on minor issues # Prefer local exit # Communities for traffic engineering 3. HEALTH CHECK to withdraw route if service fails: Health check script: if service_is_up(): announce 192.0.2.0/24 else: withdraw 192.0.2.0/24 This ensures traffic reroutes away from failed nodes. 4. SERVICE listening on anycast IP: Server binds to 192.0.2.1:53 (DNS) or 192.0.2.1:443 (HTTPS) 5. UNIQUE RESPONSE ADDRESS (for anycast source prohibition): Responses sourced from unicast management IP or anycast address if UDP only (care required)Most ISPs filter BGP announcements for prefixes smaller than /24 (IPv4) or /48 (IPv6). If you try to announce a /25 or smaller via anycast, many networks won't accept it, limiting your reach. Always use at least a /24 for IPv4 anycast, even if you only need a single IP.
We've explored anycast delivery comprehensively. Let's consolidate the essential knowledge:
What's next:
We've now covered all four packet delivery types: unicast (one-to-one), broadcast (one-to-all), multicast (one-to-group), and anycast (one-to-nearest). The final page brings them together in a comprehensive comparison, helping you understand when to use each and how they interact in modern networks.
You now understand anycast delivery—from BGP-based routing to real-world applications in DNS and CDNs. This knowledge is essential for understanding how global-scale services achieve low latency and high availability. The final page synthesizes all four delivery types for practical decision-making.