Anycast Deployment

BGP-based.

What anycast deployment is

Anycast advertises the same IP address from multiple physical locations and lets the internet's BGP routing send each user to the topologically nearest one. It moves traffic-steering from the application layer (DNS, GSLB) into the network layer, where it converges in seconds rather than minutes.

• Same IP, many locations. Each PoP advertises the shared address; routers along the path pick the shortest AS-path to the requester.
• Replaces or complements DNS routing. DNS-based geo-routing is bound by TTL and resolver caching; anycast bypasses both.
• Common workloads. DNS resolvers, CDN edge, public API endpoints, DDoS scrubbing services. Connectionless or short-connection traffic suits it best.
• Local capacity headroom per PoP. When a PoP withdraws routes, neighbours absorb its share of traffic; over-provision for that scenario, not the steady state.

Benefits over DNS routing

Anycast wins on convergence speed and resolver-independence. DNS caches and stale TTLs disappear from the failover story; users do not depend on their recursive resolver behaving correctly.

• Faster convergence. BGP withdrawal propagates in seconds; DNS TTL-based failover is bound by the longest cached TTL on the path.
• No resolver-cache confusion. Every user reaches the nearest PoP regardless of which DNS resolver they use, including ones that ignore TTLs.
• Implicit failover. A failing PoP withdraws its route; traffic shifts automatically to the next-nearest PoP without operator intervention.
• Latency floor per region. Each region gets the latency of its local PoP; no globally suboptimal route stuck behind a stale geo-DNS answer.

Infrastructure requirements

Anycast is not free. It needs real BGP relationships, multiple physical PoPs, and health-driven route withdrawal. Single-PoP "anycast" is just unicast with extra ceremony.

• BGP relationships. Either your own ASN with transit and peering, or a managed anycast offering from a CDN or edge provider.
• Multiple PoPs. At minimum three to absorb single-PoP failures without saturating the survivors. Two is fragile; one is unicast.
• Health-checked withdrawal. Routes must withdraw automatically on backend failure and re-advertise on recovery. Manual control is too slow for outages.
• Route-filter discipline per PoP. Strict prefix lists and AS-path filters catch misconfiguration before it leaks to the global routing table.

When anycast doesn't work

Anycast assumes a flow lands on the same PoP for its duration. BGP convergence and route flapping can move connections mid-stream, which connectionless or short-lived protocols handle gracefully and long-lived stateful protocols do not.

• Stateful services. Long-lived TLS sessions or stateful TCP suffer when convergence shifts the flow to a PoP that does not hold its state.
• TCP convergence drops. Most TCP flows survive route changes; some do not, particularly during BGP flapping or major outage events.
• WebSocket and persistent protocols. Common pattern is anycast for the initial handshake then unicast for the long-lived upgrade.
• Connection-aware routing per flow. Layer-7 stickiness or session affinity at a higher tier solves stateful traffic that anycast alone cannot.

Operating anycast

Operating anycast is a discipline of its own. Health monitoring, capacity planning, and BGP-relationship management never stop being load-bearing.

• Per-PoP health monitoring. Withdraw routes automatically on backend failure; re-advertise only after a clean health check; alarm on stuck states.
• Capacity planning for failover. Each PoP must hold its share plus a portion of any neighbour's traffic during withdrawal events.
• BGP relationship management. Transit contracts, peering at major IXPs, and route filters require ongoing operational expertise.
• Quarterly route audit. Prefix lists, AS-path filters, and RPKI ROAs drift; review them on a fixed cadence to catch policy regressions.