Anycast is an Internet addressing and routing method in which the same IP address is announced from many locations, and the network delivers each packet to one of those locations, normally the topologically nearest. In Internet addressing it sits alongside unicast, multicast and broadcast as a way of mapping one destination address to receivers, but unlike them it maps one address to many interchangeable servers while every individual conversation still reaches only one.
Anycast is not a special address type or a separate address range. An anycast address looks exactly like any other IPv4 or IPv6 unicast address; what makes it anycast is the way it is routed. Root DNS servers, public recursive resolvers, content delivery networks and DDoS mitigation services all depend on it to put a single, stable address in front of a globally distributed set of servers.
How anycast routing selects a destination
Anycast works because routers do not know that several origins exist; they simply see multiple paths to the same prefix and choose one. Each anycast site, often called a node or point of presence, announces the same prefix, for example a /24 in IPv4 or a /48 in IPv6, into the Border Gateway Protocol (BGP) from its own location. Every router on the Internet then picks the best path according to its own BGP policy.
The resulting choice is nearest in routing terms, not in kilometers. BGP prefers routes by local preference, then by shortest AS path, then by further tie-breakers, so a user in one city may reach a node on another continent if that path looks shorter or cheaper to the upstream provider. Inside a single organization, an interior protocol such as OSPF or IS-IS can perform the same selection with link costs, which gives finer and more predictable control.
The process can be summarized in a few steps, from announcement to delivery:
- Each site advertises the identical prefix to its transit providers and peers.
- Routers across the Internet learn several paths and install the single best one.
- A client sends a packet to the anycast address with no knowledge of the sites.
- The packet follows the local best path and arrives at one site, which answers from the same address.
- If a site withdraws its announcement, routers converge on the next best path, usually within seconds to a few minutes.
Because the reply comes from the same address the client contacted, the mechanism is invisible to applications. The price of that transparency is that the operator cannot directly choose which site serves which user; it can only influence routing through announcement policies.
Anycast compared with other addressing modes
Anycast is best understood as one of four delivery models that relate a destination address to its receivers. The table below compares them on the points that matter in practice.
| Model | Receivers per address | Who receives a packet | Typical use |
|---|---|---|---|
| Unicast | One | The single host that owns the address | Most ordinary traffic |
| Anycast | Many | One receiver, usually the nearest | DNS, CDNs, DDoS absorption |
| Multicast | A subscribed group | Every member of the group | IPTV, market data feeds |
| Broadcast | All hosts on a segment | Every host on the local network | ARP, DHCP discovery (IPv4 only) |
IPv6 removed broadcast entirely and formally recognizes anycast in its addressing architecture, including a reserved subnet-router anycast address in every subnet. In IPv4, anycast has no formal status at all; it is purely an operational practice built on BGP. In both protocol versions, most deployed anycast uses ordinary global unicast addresses.
Where anycast is used and why
Anycast is chosen when a service must be fast, highly available and reachable at one fixed address everywhere. Its strongest fit is with short, stateless exchanges, where a change of site between packets does little harm.
| Service | What anycast provides | Key consideration |
|---|---|---|
| Root and TLD DNS servers | Hundreds of instances behind a few addresses | Queries are short and stateless over UDP |
| Public DNS resolvers | Low latency and an easy-to-remember address | Cache contents differ between sites |
| Content delivery networks | Users reach a nearby edge cache | Long TCP sessions need stable routing |
| DDoS mitigation | Attack traffic is spread across many sites | Each site absorbs only its local share |
| NTP and 6to4 relays | Simple discovery of a nearby server | Legacy relays caused hard-to-trace failures |
The DDoS benefit deserves emphasis. Because attack sources are spread around the world, their traffic is split among the anycast sites nearest to each source, so no single site receives the full volume. An attack that would overwhelm one data center becomes a set of smaller loads that each site can filter. The same property also contains failures: a fault at one site affects only users routed to it, and only until the routes are withdrawn.
Design parameters for an anycast service
A working anycast deployment depends on a handful of routing and operational parameters. Getting them wrong produces uneven load, poor latency or outages that are hard to diagnose.
| Parameter | Typical value or practice | Effect |
|---|---|---|
| Prefix length | /24 in IPv4, /48 in IPv6 | Shorter prefixes are filtered by many networks |
| Number of sites | From 2-3 to several hundred | More sites lower latency and spread load |
| Upstream diversity | Same transit providers at each site | Consistent paths make selection more predictable |
| AS path prepending | One to three extra entries | Shifts traffic away from a busy site |
| Health-based withdrawal | Announce only while the service passes checks | Prevents traffic going to a broken site |
| BGP communities | Provider-specific tags | Limit an announcement to a region or peer set |
The most important operational rule is coupling the route announcement to service health. A routing daemon on each node, such as BIRD or FRRouting, announces the prefix only while local health checks pass. If the application fails but the route remains, the site becomes a black hole that keeps attracting traffic.
Limitations and common pitfalls
The main limitation of anycast is that routing can change in the middle of a connection. A BGP update may move a client from one site to another, and a TCP session that lands on a site with no record of it is reset. In practice, routes are stable enough that short TCP sessions and HTTPS traffic work well, but long-lived connections need extra care, such as connection state sharing or a hand-off to a unicast address.
- Suboptimal site selection: BGP chooses by policy and AS path, so some users reach a distant node even when a nearer one exists.
- Uneven load: one large provider can steer a huge user population to a single site.
- Harder troubleshooting: a fault may affect only users behind certain networks, so it must be tested from many vantage points.
- Inconsistent state: caches, logs and rate limits are local to each site unless explicitly synchronized.
- Prefix filtering: announcements longer than /24 in IPv4 or /48 in IPv6 are widely dropped.
These issues explain why operators pair anycast with monitoring from many locations and with careful traffic engineering. The table below links frequent symptoms with their usual causes.
| Symptom | Likely cause | Typical remedy |
|---|---|---|
| Users in one country reach a distant site | Provider preference or missing peering | Add peering or adjust communities |
| One site overloaded | Large network routes all users there | Prepend or add capacity nearby |
| Intermittent TCP resets | Route flapping between sites | Stabilize announcements, dampen changes |
| Traffic sent to a dead site | Route not withdrawn on failure | Tie announcement to health checks |
The simple explanation
Imagine a chain of pharmacies that all share one phone number. When you dial it, the telephone network quietly connects you to the branch closest to you, and you never need to know which branch answered. Anycast does the same for Internet addresses.
A company puts identical servers in many cities and gives them all the same address. When your computer sends a request, the Internet’s routing system delivers it to one nearby server. The result is faster answers and better resilience: if one location fails, requests simply flow to another one.
How it is used in practice
A regional DNS hosting provider runs authoritative name servers for about ten thousand customer domains. Its original setup had two unicast servers in one data center, and a single network outage there made every customer domain unresolvable.
The provider moves to anycast. It obtains a /24 IPv4 prefix and a /48 IPv6 prefix, places DNS nodes in six data centers on three continents, and configures each node to announce both prefixes over BGP only while local DNS health checks succeed. Customers keep the same two name server addresses throughout the migration.
After the change, median query latency for distant users falls noticeably because they reach a nearby node. Months later, a volumetric DDoS attack of several hundred gigabits per second hits the service. The traffic splits across the six sites, two of them saturate briefly and withdraw their routes, and resolution continues from the remaining four sites without any customer-visible outage.