Anycast locality is determined by routing

An anycast deployment advertises reachability to a shared service address or covering prefix from several service locations. From a particular client, the routing system selects a path and therefore a receiving location. The set of clients whose current paths lead to one location is often called its catchment. A catchment can change when a link fails, an announcement is withdrawn, or another network changes policy. It is not necessarily a stable geographic polygon or an equal share of global demand.

Anycast and DNS-based selection operate at different points. DNS can return different addresses according to its policy and cache behavior; anycast can keep the address identical while routing changes the receiving site. Combining them does not erase either layer's failure modes. To investigate locality, record the client's network, the returned address, the actual receiving site, and the relevant routes. A traceroute alone may not identify the serving process or its current load, so include application-level site identification where appropriate.

A site can have a healthy router while its service is unable to answer useful requests. Continuing to advertise the anycast prefix may then draw clients into a blackhole at the application layer. Conversely, withdrawing a route for every brief noisy health check can create churn and move too much traffic elsewhere. Connect advertisement decisions to explicit health criteria, observation windows, and available fallback capacity. Test the withdrawal path as well as normal service, because a detector without a functioning routing action does not restore reachability.

Multiple sites improve availability only when failures and routing behavior permit the alternatives to help. Shared dependencies, configuration pushes, or upstream providers can fail together. Even with an independently healthy site somewhere, clients may still route to an unhealthy advertiser until withdrawal propagates. An ideal independent-site calculation is therefore a useful benchmark for assumptions, not a production SLA. Verify both that an alternative exists and that affected clients actually move to it under the tested failure.

A transport connection can begin at one site and later have packets delivered to another after a routing change. The new site may lack the original connection's state, so using the same destination address does not guarantee continuity. Per-flow forwarding stability on one router also cannot guarantee that every network on a changing path keeps the same site. Short stateless exchanges and long-lived stateful sessions therefore place different demands on the deployment. State sharing, flow handoff, or connection-aware redirection require explicit mechanisms beyond anycast itself.

Use the probability lab with p interpreted as independent site availability and n as site count. Predict the zero-available-sites bar and compare its complement with the ideal formula. The bars enumerate a binomial model; they do not choose a route, model correlated regional failures, or retain transport state. Then name a real deployment condition that would prevent an available site from rescuing a client. This separates redundancy on paper from tested failover and makes the limits of the calculation visible.