Anycast

How anycast actually delivers packets

The default Internet addressing model is unicast: one IP belongs to one server, and routing tables list exactly one path to that IP. Anycast breaks the assumption. Many servers share the same IP, and each one independently announces the prefix containing that IP into BGP. The global routing table now contains many paths to the same prefix, originating from different ASes or different points in the same AS.

BGP's path-vector selection silently does the work: each router picks its single best path to the prefix using the standard tiebreakers (LOCAL_PREF, AS_PATH length, MED, IGP cost). The result is that every router on the Internet has chosen one anycast instance as its destination — the one closest to it by routing policy. A user in Berlin sees Frankfurt; a user in Sydney sees the Sydney instance; nobody changed any DNS.

The four addressing models compared

Model	One IP maps to	Used for	Routing
Unicast	One server	Default Internet — every web server	One best path
Multicast	Subscribed group	IPTV inside ISPs, financial market data, IPv6 ND	Tree of receivers
Broadcast	Every host on a subnet	ARP, DHCP discovery (link-local only)	Subnet flood
Anycast	The closest of N servers	DNS roots, public resolvers, CDN edges	BGP picks one

How operators announce an anycast prefix

Two requirements. First, the operator must own (or be authorized to announce) an IP prefix — typically a /24 for IPv4 (the smallest globally-accepted route) or /48 for IPv6. Second, the same prefix must be announced from every PoP that participates.

Inside one AS, this is straightforward: each PoP's router originates the same prefix into iBGP and eBGP, and the operator ensures the upstream peers accept and propagate the announcement. The BGP best-path selection at each remote AS handles the rest — there is no central directory of "which PoP serves which user."

# Example FRRouting config — announce 192.0.2.0/24 from this PoP
router bgp 65001
  network 192.0.2.0/24
  neighbor 198.51.100.1 remote-as 65000
  neighbor 198.51.100.1 prefix-list ANYCAST out
!
ip prefix-list ANYCAST permit 192.0.2.0/24

# Verify the announcement is being seen at a public looking glass
$ curl -s 'https://stat.ripe.net/data/looking-glass/data.json?resource=192.0.2.0/24' | jq

DNS root servers — the canonical anycast deployment

The 13 root server letters (A through M) serve every uncached lookup for top-level domains. As of 2026 the system handles roughly 1.5 trillion queries per day. No single machine could absorb that, so each letter is a cluster of hundreds of identical anycast servers:

Letter	Operator	Approximate anycast instances
A	Verisign	120+
F	Internet Systems Consortium (ISC)	250+
K	RIPE NCC	100+
L	ICANN	200+
...	...	...
Total	12 organizations	~1500 (root-servers.org)

An additional benefit: the 13-letter limit was a UDP DNS packet-size constraint from the 1980s, not a count of physical servers. Anycast removes the scaling concern entirely.

Public resolvers and the rise of 1.1.1.1

Cloudflare's 1.1.1.1 (launched 2018) is announced from every Cloudflare PoP. A user in Mumbai querying 1.1.1.1 reaches the Mumbai PoP; a user in São Paulo reaches São Paulo — same IP, dramatically different physical machines. Median resolution latency for 1.1.1.1 is 8-15 ms globally. Google's 8.8.8.8 (launched 2009) and Quad9's 9.9.9.9 use the same model.

Public resolver	Operator	Anycast PoPs	Notable feature
1.1.1.1	Cloudflare	300+	Privacy-first, no-logs claim
8.8.8.8	Google	large	EDNS Client Subnet support
9.9.9.9	Quad9	200+	Threat-blocking by default
208.67.222.222	OpenDNS / Cisco	large	Family-safe categories

TCP and TLS — the careful part

Anycast is trivially safe for stateless protocols. UDP DNS sends one query, gets one response — even if the next query lands on a different node, both nodes have the same authoritative answer.

Stateful protocols are harder. A TCP connection involves sequence numbers, window state, and TLS keys held only by the originating server. If BGP routes shift mid-flight, packets land on a node that has no memory of the connection and replies with RST. Real-world risks:

• Peering changes. A transit provider drops a session; routes withdraw and re-converge. Connections moving across the boundary die.
• Backbone reroutes. An MPLS path reconverges inside a Tier-1; the egress interface for a destination changes; a different anycast PoP becomes closest.
• Anycast at the edge of the AS. The user is hashed to a different egress interface by the customer's ECMP router, even within one PoP — internally this is multipath unicast, but if PoPs share a frontend layer it can have similar effects.

Empirical Cloudflare data shows ~99.5% of TCP connections stay on a single anycast PoP for their lifetime. Long-lived sessions (WebSockets, RTMP, HTTP/3 pings) are more exposed and benefit from connection migration features — QUIC's built-in connection ID is partly motivated by this problem.

Failover via BGP withdrawal

One of anycast's biggest operational wins: failover is automatic. When a PoP goes offline, its BGP daemon stops sending KEEPALIVEs to its upstream and the session times out — typically within 30-180 seconds. The upstream withdraws the prefix toward the rest of the Internet, and BGP best-path selection on every other AS picks the next-closest PoP automatically.

For faster failover, operators use BFD (Bidirectional Forwarding Detection, RFC 5880), which detects link death in 50-300 ms by exchanging UDP probes, and tear down the BGP session immediately. With BFD plus anycast, traffic shifts from a dead PoP to its peers in well under a second.

DDoS absorption

An anycast deployment naturally distributes inbound attack traffic. Suppose attackers fire 1 Tbps from a botnet of 100,000 hosts. Each bot's traffic follows BGP toward the destination IP, but each bot's "closest" PoP differs. The 1 Tbps gets fragmented across hundreds of PoPs — perhaps 3-5 Gbps per PoP — well within a single PoP's capacity to filter and drop.

Cloudflare publicly claims 248 Tbps of distributed mitigation capacity. AWS Shield Advanced sits behind CloudFront's anycast layer and offers similar dispersion. The defender gets a multiplier: the attacker has to find more, geographically diverse bots to overwhelm any single PoP.

Verifying anycast from your laptop

# Which PoP is 1.1.1.1 from your network?
curl https://1.1.1.1/cdn-cgi/trace
# Output:
#   ip=...
#   colo=FRA   <-- Frankfurt
#   loc=DE

# Same query from a different network may return a different colo
ssh aws-tokyo "curl -s https://1.1.1.1/cdn-cgi/trace | grep colo"
# colo=NRT

# Trace to see the AS path
mtr --aslookup --report --report-cycles 5 1.1.1.1

# Check anycast announcements at RIPE RIS
curl -s 'https://stat.ripe.net/data/announced-prefixes/data.json?resource=AS13335' | jq '.data.prefixes[] | select(.prefix == "1.1.1.0/24")'

# DNS chaos query — see which root instance you actually hit
dig @a.root-servers.net hostname.bind chaos txt
# returns identifier of the specific physical instance

Why anycast matters

• Latency. Replace a 200 ms transcontinental path with a 10 ms regional one without changing anything client-side.
• Failover. A dead PoP withdraws its announcement; traffic shifts in seconds. No manual DNS changes, no TTL waits.
• DDoS absorption. Botnet traffic disperses across the operator's entire footprint; the per-PoP load stays manageable.
• Scalable DNS. The 13 root letters serve trillions of queries via 1500 physical instances; without anycast the model would have collapsed in the 1990s.
• Public resolvers. 1.1.1.1, 8.8.8.8, 9.9.9.9 — one IP, many physical answers, low latency for everyone.
• Operational simplicity. One IP, one cert, one config; BGP does the hard part.

Common misconceptions

• "Round-trip ping doesn't lie." Anycast IPs can take asymmetric paths — outbound to PoP A, inbound from PoP B if return routing differs. Ping RTT only tells you the closer of the two.
• "TCP doesn't work." TCP works fine if BGP is stable; most production CDNs run anycast TCP at scale. The risk is route changes mid-connection, not anycast itself.
• "Anycast is just magic load balancing." Granularity is BGP-table size — typically per-AS or per-prefix. You can't anycast at per-request granularity; that's L7 load balancing.
• "All public IPs can be anycasted." You need to own the prefix and have the routing relationships to announce it from multiple ASes (or one AS with many transit providers). Random VMs cannot do anycast.
• "Source IP tells you where the user is." Yes, but the destination IP (the anycast IP) tells you nothing about where they connected — every anycast user sees the same destination.
• "Anycast equals geo-routing." BGP picks by AS-path length and policy, not geography. A user in Tokyo can end up routed to Singapore if Singapore is closer in BGP terms.
• "Anycast is rare." Almost every major CDN, every public DNS resolver, and the entire DNS root system run on anycast. It is one of the most-used techniques on the modern Internet.