Anycast
Anycast works by having multiple physically separate points of presence (PoPs) originate BGP announcements for the exact same IP prefix. Every router in the path runs its normal best-path selection algorithm (AS-path length, MED, local preference, IGP metric) against these competing announcements, and traffic converges toward whichever origin is topologically cheapest from that router’s perspective — which usually, but not always, correlates with geographic proximity. There is no anycast-specific protocol extension; it is a routing-table side effect of announcing one prefix from many autonomous origins, which is why it composes cleanly with existing BGP tooling, route reflectors, and route dampening policies.
The critical operational subtlety is granularity. Anycast steering happens at the route level, not the flow or connection level. Once a router has committed to a next-hop for a prefix, all packets to that destination follow the same path until the routing table changes — a link failure, a BGP session reset, a traffic-engineering change, or a health-check-triggered route withdrawal at the origin. When that happens mid-connection, packets belonging to an established TCP stream can suddenly land on a completely different physical node with no shared connection state, producing a silent RST or a stalled stream. This is the core reason anycast is safe for stateless, idempotent, short-lived exchanges (DNS queries, ICMP probes, QUIC/UDP handshakes) but dangerous for long-lived stateful sessions unless a stable overlay is established after the initial anycast hop.
Health-based failover is implemented operationally, not protocol-natively: each PoP runs a local health check against its service, and on failure it withdraws its BGP announcement (or lowers its preference), causing global convergence to redirect traffic to the next-best origin within one BGP convergence interval — typically sub-second to a few seconds depending on session type (eBGP multihop vs. direct peering) and dampening configuration. This is the mechanism DNS root servers, public resolvers (1.1.1.1, 8.8.8.8), and CDN edge networks rely on for fast, coordination-free failover across dozens of global sites. It also underlies anycast-based DDoS scrubbing: volumetric attack traffic is naturally diffused across every advertising PoP simultaneously, diluting the attack’s effective concentration per site rather than requiring a single choke point to absorb the full load.
Two failure modes recur in production. First, ECMP flow-hashing interaction: when multiple equal-cost paths exist toward the same anycast prefix, routers hash the packet 5-tuple to pick a next-hop consistently per flow — but a topology change (link flap, new peer session) can alter the hash bucket assignment and reroute an in-flight flow even without a route withdrawal. Second, asymmetric routing: the return path from an anycast-served node back to the client may transit different infrastructure than the forward path, which breaks stateful middleboxes (firewalls, NAT) expecting symmetric flows and complicates source-IP-based debugging. Production systems that need anycast’s fast-failover properties but also need session stability (Google’s GFE, AWS Global Accelerator, Cloudflare Spectrum) resolve this by using anycast only as the ingress entry point, then immediately re-encapsulating traffic onto a private, unicast-addressed backbone or overlay tunnel to a stable regional endpoint — decoupling the anycast convergence domain from the application’s session lifetime.
Anycast is therefore best understood as a routing-layer load-distribution primitive with failover as a side effect of BGP convergence, not a session-aware load balancer. Architecturally, its value is greatest at the extreme edge of a system — DNS, initial connection handshakes, DDoS-facing ingress — where the cost of an occasional mid-flow reroute is negligible, and its risk is greatest wherever connection state has any lifetime longer than a single round trip.