Anycast has quietly become the invisible scaffolding of the modern internet. Root DNS servers, CDN edge networks, DDoS scrubbing centers, and public resolvers like 1.1.1.1 all depend on it. Announce the same IP prefix from dozens of locations, let BGP sort out the topology, and clients magically reach the nearest instance. The elegance is seductive.

But the elegance is also deceptive. What appears to operators as a simple routing trick becomes, at scale, a complex negotiation between control-plane dynamics, data-plane realities, and application semantics. The internet was not designed to make anycast easy. It was designed to route packets, and anycast borrows that machinery for a purpose it was never explicitly engineered to serve.

The consequences ripple outward. Catchments — the sets of clients that reach a given instance — shift unpredictably as BGP recomputes best paths. Load distribution rarely matches geographic intuition. Stateful protocols must contend with the possibility that consecutive packets from the same client may terminate at different nodes. Each of these challenges has been studied, mitigated, and productionized, yet none has been fully solved. Understanding why requires looking closely at the mechanics beneath the abstraction and confronting the operational reality that anycast is less a service model than a discipline.

Anycast begins with a deceptively simple act: announcing an identical IP prefix from multiple points of presence, each with its own BGP session upstream. Every transit provider and peer independently evaluates these announcements and installs whichever path its policy engine prefers. There is no coordination, no central arbiter, no consensus. The global routing table becomes the distributed decision-making substrate.

The catchment of any given instance is therefore an emergent property of thousands of independent policy decisions. AS-path length, local preference, MED values, hot-potato routing, and peering agreements all conspire to shape which clients land where. Geographic proximity correlates loosely with network proximity, but the correlation frays quickly. A client in São Paulo may reach an instance in Miami rather than one twenty kilometers away, simply because a transit provider prefers a shorter AS-path over physical distance.

Operators shape catchments through a limited toolkit. AS-path prepending, community-tagged announcements, selective peering, and MED manipulation offer coarse control. More sophisticated deployments use per-peer prefix announcements or leverage BGP communities defined by transit providers to influence propagation. Yet each lever affects only the paths its neighbors accept and readvertise, and downstream behavior remains opaque.

The result is that anycast operators must instrument heavily to understand their own service. RIPE Atlas measurements, passive flow telemetry, and per-instance query logging all become mandatory. Without empirical catchment maps, engineering intent and observed behavior drift apart. A prefix intended to serve Europe from Frankfurt may find itself absorbing traffic from West Africa or the Middle East based on subtle peering asymmetries.

Anycast is thus not routing by geography but routing by policy, expressed through a protocol that predates the very idea of anycast as an application pattern. The abstraction works because BGP is remarkably tolerant of prefix duplication, but the operator pays for that tolerance in observability and control.

Takeaway

Anycast catchments are not designed — they are discovered. The map you build in your head is always an approximation of what BGP has actually decided on your behalf.

A stable anycast deployment is a snapshot in time. BGP is a dynamic protocol, and every session flap, policy change, prefix withdrawal, or new peering relationship somewhere in the global graph has the potential to shift catchment boundaries. Clients that reached instance A for months may suddenly land on instance B, not because anything at either instance changed, but because a distant AS updated its route selection.

These shifts are usually invisible to end users when the service is stateless. A DNS query resolves identically at any instance, so a mid-session catchment change costs nothing. But even for stateless services, catchment churn manifests as cache locality loss, uneven capacity utilization, and confused metrics. Operators observing sudden traffic spikes at one PoP must distinguish organic demand from routing-induced redistribution.

Planned changes — draining a PoP for maintenance, adding capacity in a new region, adjusting peering — are the most manageable form of instability. Techniques such as gradual prefix withdrawal, graceful BGP session shutdown, and controlled community-based path adjustments allow operators to shift catchments deliberately. Anycast slow drain, where announcements are progressively de-preferred rather than withdrawn, minimizes the shock to downstream state.

Unplanned instability is harder. Transit outages, upstream flaps, and remote route leaks can cause catchment shifts measured in seconds. Some deployments respond with route dampening at the edge, others with BFD-triggered fast failover, others still with application-layer redirection that anticipates BGP convergence rather than depending on it. The chosen strategy trades convergence speed against oscillation risk.

The deeper lesson is that anycast stability is a control problem, not a configuration problem. The operator must actively manage the rate at which catchments change, because unmanaged change is indistinguishable from failure at the application layer.

Takeaway

In anycast, failover is not a discrete event but a continuous property of the routing system. Stability must be engineered, measured, and defended.

Stateless protocols suit anycast naturally. A DNS query over UDP requires no continuity: the packet arrives, the response returns, and any subsequent query is independent. This is why anycast first flourished in the DNS root and TLD infrastructure. The moment protocols require state, however, the abstraction begins to strain.

TCP is the canonical challenge. A connection is a four-tuple bound to a specific endpoint, and mid-connection catchment shifts mean subsequent packets arrive at an instance with no matching socket. The connection resets, the application observes an error, and the user experiences a stall. For short-lived HTTP/1.1 connections this is tolerable; for long-lived HTTP/2 streams, WebSockets, or QUIC migrations initiated by the network rather than the client, it is corrosive.

Several mitigations have emerged. Some operators deploy stateful load balancers that use consistent hashing to backhaul flows to a stable anycast instance regardless of ingress point, effectively converting anycast into a discovery mechanism while unicast carries state. Others rely on connection-ID-aware transports like QUIC, which decouple session identity from the IP tuple and allow graceful migration across path changes.

Application-layer session management adds another dimension. Even when TCP survives, session state — authentication tokens, shopping carts, in-progress transactions — must be either replicated globally, stored client-side, or reconstructible from a shared backend. Global state replication introduces consistency and latency costs; client-side state introduces trust and size constraints; shared backends reintroduce the centralization anycast was meant to alleviate.

The frontier here is transport evolution. QUIC's connection migration, multipath extensions, and emerging protocols that treat network paths as ephemeral rather than identifying suggest a future where anycast and stateful communication are less at odds. But that future requires the transport layer, not just the routing layer, to embrace mobility as a first-class property.

Takeaway

Anycast reveals a hidden assumption in our protocol stack: that a destination address is a stable identity. Every stateful service built on anycast is really a workaround for that assumption.

Anycast is one of the internet's most productive misuses of an existing mechanism. BGP was designed to find a path to a destination; anycast asks it to find a path to a destination, and the protocol obliges with a shrug. That the resulting system carries a substantial fraction of global DNS, CDN, and edge traffic is a testament to both the flexibility of the internet's core protocols and the ingenuity of the operators who tame them.

The remaining challenges — catchment observability, controlled failover, and stateful continuity — point toward a networking future in which identity and location are more thoroughly separated. QUIC, segment routing, and application-aware overlays each chip away at the assumption that an IP address names a single machine at a fixed place.

Until then, anycast will remain a discipline as much as a technology: a practice of shaping emergent behavior, measuring what routing actually does, and building services robust enough to survive the ambiguity.