A user in Lagos reaches your anycast address at your Frankfurt location while a nearer location in Johannesburg sits idle. Nothing is broken and no configuration has changed. Which explanation is correct?

What is being tested

Whether you know that internet routing is an economic and administrative system that happens to move packets, rather than a latency-optimising one. This single misunderstanding is behind most surprise in anycast deployments.

The mechanism

A BGP speaker chooses between candidate routes to the same prefix using an ordered decision process standardised in RFC 4271 (2006). The first tie-breakers that matter in practice are:

1. Local preference - a number the network operator sets to express commercial preference. A transit provider that is cheaper, or a peer that is settlement-free, is preferred regardless of performance.
2. AS-path length - the number of autonomous systems traversed. This is a hop count over organisations, not over routers, and not over distance. A path through 2 very large networks that physically crosses two continents beats a path through 4 regional networks next door.
3. Origin type, multi-exit discriminator, then eBGP over iBGP, and finally the lowest IGP cost to the exit - "hot potato" routing, which hands traffic to the next network at the nearest exit rather than the best one.

Nowhere in that list is a round-trip time. So a Lagos ISP that buys transit from a provider whose nearest interconnect with your network is in Frankfurt will send your traffic to Frankfurt, which may be 90 to 150 ms away, while Johannesburg at 15 ms is reachable only via a path that ISP does not buy or does not prefer. The African case is the standard example because regional interconnection is thin: traffic between two African networks has historically often transited Europe, which is why local internet exchange points are an infrastructure priority rather than a technicality.

Why the other options fail

• "BGP measures latency." It has no mechanism to. Operators add latency awareness on top - real-user measurement feeding DNS or edge steering, or traffic engineering that rewrites local preference - but the protocol itself carries no performance signal.
• "Stale DNS record." Plausible for a DNS-steered deployment and impossible for anycast, where every location answers on the same address and the resolver has no location to be wrong about. Knowing which steering mechanism is in use is half the diagnosis.
• "TCP congestion control steered it." Congestion control adjusts the sending rate on a path already chosen. It cannot select a path and has no visibility of one.

When this is the wrong model to apply

When the deployment is not anycast. With DNS-based or edge-based steering, the choice really is yours and really can be latency-driven, so a user reaching a distant location is a steering bug and should be investigated as one. Identify the steering mechanism before diagnosing the path: anycast means the question is "what does the internet think", DNS steering means the question is "what did we say". Anycast also remains the right choice for raw reachability and for absorbing volumetric attacks, where the goal is that every location can serve rather than that the nearest one does.