What is Anycast Routing?
Updated: 3 days ago
Anycast routing is a network routing technique where the same service IP address is made reachable from multiple separate locations, allowing the routing system to direct traffic to one available anycast node. On the public internet this is commonly achieved by advertising the same IP prefix from multiple locations using BGP.
The important distinction is that anycast does not inherently send a user to the geographically nearest server, the least loaded server or the server with the lowest latency. The routing system selects a path according to its topology and routing policy. That path can often be useful and local, but physical distance and performance are not guaranteed by anycast itself.
What does anycast routing mean?
RFC 4786 defines anycast as making a particular service address available in multiple discrete, autonomous locations so packets are routed to one of several available locations. RFC 4786: Operation of Anycast Services is the IETF Best Current Practice covering the operation of anycast services.
The service address is stable from the client's perspective. What changes is the network location that can receive traffic for it. Each anycast node presents a path to that same service address, and routing determines which path is selected from a particular part of the network.
Anycast routing in one sentence
Anycast routing lets multiple network locations advertise reachability to the same service IP address so routing can direct each client towards one available location.
How does anycast routing work?
At internet scale, anycast normally relies on BGP. Multiple sites advertise reachability to the same prefix. Other networks learn those advertisements, apply their own routing policies and select routes in the normal way.
A service is configured behind two or more physically separate anycast nodes.
The same service address or prefix is made reachable from each participating node.
Each node advertises reachability into the relevant routing system.
Networks receiving those advertisements apply routing policy and select an eligible path.
Packets addressed to the anycast service follow the selected route and arrive at one of the nodes.
If reachability changes or a route is withdrawn, routing can converge on another available path.
Anycast therefore builds on normal routing rather than creating a separate packet forwarding system. The routing table still determines the next hop. Anycast changes the fact that several locations can legitimately originate reachability for the same service address.
Anycast does not mean the geographically nearest server
This is one of the most important misconceptions to remove. Routing protocols understand network paths and policy, not a map showing straight line distance from the user. A node in London may be physically closer to a UK user than a node in Amsterdam, but the selected route depends on which advertisements the user's network receives and prefers.
RFC 4786 explicitly warns that topological nearness does not generally correlate with round trip performance. Response times can improve, remain similar or even become worse depending on how the routing system selects the node.
This is closely related to why a lower hop count does not automatically mean lower latency. Routing path, physical distance, interconnection, congestion and queueing all matter.
Anycast versus unicast
Unicast normally associates an address with one network destination at a time. Anycast deliberately makes the same service address reachable through multiple locations. A client still sends an ordinary IP packet to one destination address, but the network can deliver that packet to one of several nodes advertising the address.
Unicast: one destination address is normally routed towards one specific network location.
Anycast: the same service address is available from multiple discrete locations.
Unicast failover often requires another mechanism to move or replace reachability.
Anycast can use routing changes to shift traffic towards another available node.
Anycast node selection is routing driven, not an application level request for a particular site.
What is an anycast node?
An anycast node is a location that provides the service associated with the anycast address and presents a unique route to that address. A node can be simple or can contain routers, load balancers and multiple servers behind the routing edge.
The service exposed by each node generally needs to behave consistently enough that a client can use whichever node routing selects. That makes data synchronisation, configuration consistency and health signalling important operational concerns.
How BGP is used for global anycast
For internet wide anycast, BGP allows the same prefix to be advertised from multiple sites. The advertisements can reach networks through different peering and IP transit relationships.
BGP does not receive a special instruction saying 'choose the nearest anycast server'. It sees multiple possible routes to the prefix and applies normal route selection and policy. Commercial relationships, local preference, AS path information and other policy choices can influence which advertisement wins.
This also means two broadband users in the same UK town can theoretically reach different anycast nodes if their providers have different interconnection and routing policies.
A practical UK anycast example
Imagine a service using the same anycast address from nodes in London, Manchester, Amsterdam and Frankfurt. A customer on one UK broadband network may reach London because that provider has a preferred route there. Another UK customer may be carried towards Manchester. A third provider could prefer a route that reaches the service through mainland Europe.
The address used by the application does not need to change. The network path determines which service location receives the traffic. If the London advertisement disappears, affected networks can reconverge and select another available advertisement, subject to BGP propagation and policy.
The infographic below shows the central idea: one service address can exist at multiple network locations, while routing topology and policy determine which node receives traffic.
Techie Broadband path analysis: fewer kilometres is not the anycast rule
Consider two theoretical anycast paths from a UK user. Node A is 250 km away in physical terms but the selected network route involves an indirect interconnection. Node B is 450 km away but the user's ISP has a strong direct peering path towards the network hosting that node.
Node A is about 44.4% closer by straight line distance in this theoretical example: (450 − 250) ÷ 450 × 100 = 44.4%. That does not mean Node A will have 44.4% lower latency or that BGP must choose it. Physical distance is only one contributor to end to end delay, and the routing system does not select an anycast node by applying that distance calculation.
The useful conclusion is not that distance is irrelevant. It is that anycast creates multiple routing opportunities. The quality of the resulting path still depends on topology, interconnection, policy and current network conditions.
Why is anycast routing used?
Anycast is attractive because one stable service address can be distributed across infrastructure in multiple places. The design can improve resilience and scale, and it can help keep some traffic closer in routing terms to the users generating it.
Resilience: several nodes can provide the same service rather than depending on one site.
Coarse traffic distribution: demand can be spread across multiple nodes, although not necessarily evenly.
Service locality: routing can direct some users towards a topologically closer service location.
Failure handling: withdrawing an unavailable route can allow traffic to converge towards another node.
DDoS containment: distributed nodes can help localise or absorb attack traffic rather than concentrating all traffic at one site.
Operational simplicity for clients: users can continue addressing one stable service IP rather than selecting a regional address themselves.
Anycast is not conventional load balancing
Anycast can distribute traffic, but RFC 4786 cautions that load balancing between anycast nodes is typically difficult and generally unbalanced. BGP is not measuring the CPU utilisation or request queue of every anycast server before selecting a route.
Operators can influence traffic through routing policy, node placement and advertisements, but fine grained request balancing is usually handled by systems inside or in front of the selected node. Anycast is better understood as routing based service distribution than as a replacement for every form of load balancer.
Anycast and DNS
DNS is one of the classic uses of anycast because a DNS service can be offered from many locations behind the same service address. Cloudflare's explanation of Anycast DNS describes how queries to an anycast resolver can be answered by different nodes in its distributed network.
DNS transactions are also often short lived, which fits an important anycast design consideration: the routing system's node selection should remain stable for longer than the transaction that depends on it.
Anycast and content delivery networks
Content delivery and edge networks can use anycast to expose services from many points of presence. A user connects to the same advertised service address, while routing steers the traffic towards one reachable edge location.
Anycast alone does not guarantee that the selected edge has the requested content cached, nor does it define what happens between the edge and an origin server. Those are separate application and platform design decisions.
Anycast and DDoS resilience
Distributing an address across many nodes can increase the number of places where attack traffic can be received and processed. RFC 4786 identifies localising denial of service damage and constraining distributed attacks or flash crowds to regions around anycast nodes as possible goals.
That does not make anycast a complete DDoS defence by itself. Capacity, filtering, detection, upstream relationships and the distribution of attack sources all matter. Anycast is one architectural tool within a wider mitigation design.
What happens when an anycast node fails?
A robust deployment needs routing reachability to reflect service health. If a node can no longer provide the service, its route can be withdrawn or otherwise made less preferable so traffic can converge towards another node.
The critical operational detail is that a router being alive does not necessarily mean the application behind it is healthy. Health checking must therefore be designed so a failed service is not left attracting traffic simply because the routing process is still advertising the prefix.
Route changes can move an active client
Anycast depends on route stability. If the preferred route changes during a transaction, subsequent packets can reach another node. This makes route flapping and convergence behaviour particularly relevant to stateful or long lived services.
Short request and response transactions are generally easier to distribute safely than sessions that depend on local state for a long time. Modern application architectures can mitigate this through shared state, replication or other design choices, but the service must be engineered for the routing behaviour it will experience.
Anycast and asymmetric routing
The outbound and return paths across the internet do not have to be identical. Asymmetric routing can therefore exist alongside anycast. The anycast node selected for traffic in one direction does not imply that every packet in the opposite direction follows the same sequence of networks in reverse.
This matters when interpreting traceroute results, firewall state, latency measurements and network incidents. Anycast adds another reason to think in terms of routing from a particular observation point rather than assuming one universal path.
IPv4 and IPv6 anycast
The operational principles in RFC 4786 apply to services reachable over both IPv4 and IPv6. An operator can distribute service addresses in either protocol family, provided the routing and service design support the deployment.
IPv4 and IPv6 should still be treated as separate routing environments. A user can reach the same service over different prefixes and potentially different interconnection paths, so the selected anycast location or performance does not have to be identical between the two protocols.
How can you tell whether a service uses anycast?
There is no single test from one broadband connection that proves a service is anycast globally. The useful evidence comes from comparing routing and network observations from multiple locations.
Resolve or identify the service IP address you want to investigate.
Run traceroute or equivalent path tests from your own connection and record the final path and latency.
Repeat the observation from genuinely different networks or geographic locations.
Compare BGP route visibility for the relevant prefix from multiple vantage points.
Look for operator documentation that explicitly states the address or service is anycast.
Repeat tests over time because routing changes can alter which node a vantage point reaches.
A low latency result by itself is not proof of anycast. Equally, different traceroute paths do not prove that the final service is physically hosted in different places. Use several forms of evidence.
Common anycast misconceptions
Anycast always chooses the geographically nearest server. It does not. Routing topology and policy choose the path.
Anycast always gives the lowest latency. It can improve locality, but lowest round trip time is not guaranteed.
Anycast evenly load balances traffic. Distribution is often coarse and unbalanced.
Every anycast node must be one physical server. A node can contain a wider service platform behind its routing edge.
Anycast removes the need for application resilience. The service still needs health checks, consistent behaviour and appropriate state management.
Anycast is only for DNS. DNS is a prominent use case, but the technique can distribute other suitable services.
Anycast routing and UK broadband users
For a UK broadband user, anycast can influence which DNS resolver, CDN edge, security platform or other distributed service receives a connection. The experience depends partly on the broadband provider's own routing and interconnection.
A provider with direct peering towards a distributed service may select a different anycast path from a provider relying on another exchange point or transit route. Access technology such as FTTP is only one part of the end to end path. Once traffic leaves the access network, routing and interconnection become increasingly important.
This is why two users with similar headline broadband speeds can see different latency to the same anycast service. The retail speed tier does not define the entire internet path.
Troubleshooting a suspected anycast routing issue
Confirm the problem is destination specific rather than affecting the entire broadband connection.
Record the service IP address and whether the connection is using IPv4 or IPv6.
Run repeated latency and traceroute tests rather than relying on one sample.
Compare results from another network, such as a separate broadband provider, where practical.
Check whether the service operator publishes status information for regional or edge locations.
Look for a sudden path change, large latency change or repeated route instability at the same time as the problem.
Test again later to determine whether routing convergence moved the connection to another node.
If reporting the fault, provide timestamps, source ISP, destination IP, protocol family and path evidence rather than simply stating that the nearest server is not being used.
Do not automatically assume that an unexpected geographic path means the ISP or service is faulty. Internet routing is policy based, and the location inferred from an IP address or traceroute hostname can itself be misleading.
Frequently asked questions about anycast routing
Is anycast the same as load balancing?
No. Anycast distributes traffic using routing reachability. It can spread demand between nodes, but it does not inherently balance requests evenly or make per request decisions based on server utilisation.
Does anycast always use BGP?
No. RFC 4786 discusses both local scope anycast using an Interior Gateway Protocol and global internet anycast using BGP. BGP is the important mechanism for internet wide anycast.
Does anycast always reduce latency?
No. A well designed deployment can improve locality for many users, but routing nearness is not the same as physical distance or guaranteed lowest round trip time.
Can the same IP address exist in several data centres?
Yes. That is the central anycast idea. Multiple nodes can make the same service address reachable, with routing deciding which location receives traffic from a given source.
Can an anycast route change while I am connected?
Yes. Routing changes can alter the preferred node. Whether that disrupts an application depends on the protocol, transaction duration, state handling and how the service is engineered.
Is anycast used with IPv6?
Yes. The IETF anycast operational guidance applies to services reachable over both IPv4 and IPv6.
Key takeaway
Anycast routing makes one service address reachable from multiple network locations and lets the routing system select one available path. It can improve resilience, scalability and routing locality, but it should not be described as a guarantee of the geographically nearest server, the lowest latency or perfectly balanced traffic. For UK broadband users, the anycast node reached depends on the wider combination of ISP routing, BGP policy, peering, transit and current network conditions.
To explore the related technical concepts used in this Anycast Routing guide, visit our broadband terminology guide.
