Anycast was first described in RFC 1546 in 1993, as a way to let one IP address stand for a whole group of hosts, with the routing system delivering each packet to whichever member is closest. It still matters because it is the structural reason a large volumetric flood can be absorbed at all, and the reason a DDoS test of an edge network has to think about where its own traffic comes from. The same address is announced in BGP from many locations at once, so mitigation providers, CDNs and DNS operators spread incoming load across regional points of presence instead of concentrating it on one link.
Nearest means nearest in BGP
"Closest" in anycast is a routing decision, not a map distance. Each network on the internet picks a path to the announced prefix using its own BGP policy: shortest AS path, cheapest transit, local preference. The set of sources that end up at a given point of presence is called its catchment, and catchments follow the shape of the internet's peering rather than national borders. A user in one city can land on a PoP in another country because that is where their provider's transit happens to hand off.
TCP works over anycast because those routes are stable for far longer than a typical connection. When a route does change mid-flow, the packets arrive at a different PoP that has no state for the connection, and the session resets. Operators accept that rare cost in exchange for the absorption. The operational practice is written down in RFC 4786 (BCP 126).
Why it matters under attack
Anycast divides an attack by the attacker's topology, not evenly. A botnet concentrated in one region, or behind a handful of large consumer providers, lands mostly on the PoPs serving those catchments. The aggregate capacity of the network is the wrong number to compare against the flood; the capacity of the busiest PoP is the right one. A provider quoting hundreds of terabits of total edge capacity is describing every PoP at once, and no single flood reaches all of them.
The design has proved itself in public. All thirteen DNS root server identities are served by anycast, from more than a thousand instances between them. During the root server event of 30 November and 1 December 2015, the root operators reported peaks of roughly five million queries per second per root letter. Some instances were saturated and some letters were degraded in particular regions, but the root service as a whole stayed reachable, because the load had been divided into catchments and resolvers retried other letters.
Two operator levers come with the design. A saturated PoP can withdraw its announcement, which moves its whole catchment to the next-best PoPs: useful when they have headroom, a cascade when they do not. And the absorption only covers addresses the anycast edge actually announces. If the origin is reachable on its own address, the edge is a detour the attacker can skip, which is the subject of origin IP exposure.
What a DDoS test measures
The first thing a test has to get right is its own source geography. Traffic generated from a single cloud region lands in one catchment, so it measures one PoP, not the network. That is a legitimate test if the question is "how much can the PoP nearest our customers hold", and a misleading one if the report then claims the whole edge absorbed the volume. A useful anycast test states which catchments its sources fell into and either spreads them deliberately or targets one PoP on purpose to find its ceiling.
The second is coverage: whether every reachable path to the service passes through the anycast edge, including origin addresses, management interfaces and secondary hostnames. The third is behavior at the limit: whether a PoP that is overwhelmed withdraws cleanly, how long clean traffic in that catchment suffers before it does, and where the displaced load goes. Before any of that, it is worth confirming your own address actually lands on the edge you are paying for, which DDoS protection in the path shows how to check.