Anycast During DDoS: What Does It Distribute—and What Doesn't It?
Anycast distributes reachability across sites but does not filter an attack. Plan catchments, capacity, route withdrawal and acceptance tests correctly.
Anycast can distribute requests—and therefore some attack traffic—across several sites or constrain it to regions. It does not identify which packets are legitimate, automatically discard an attack or guarantee balanced load. Anycast therefore replaces neither DDoS filtering nor sufficient capacity, sound routing policy and a tested failure plan. It is one architectural component, not the protection mechanism on its own.
One address, several reachable sites
With anycast, the same service address is made reachable at several separate sites. Routing selects one of the available paths for a source. RFC 4786 calls the topological region whose traffic reaches a particular anycast node its catchment. The selected node follows the view and policy of the participating networks—not a central measurement of server load, response time or spare filtering capacity.
RFC 4786: operation and design of anycast services
| Component | Decision | What it does not provide automatically |
|---|---|---|
| Anycast routing | Which reachable site receives traffic for the same address | Distinguish legitimate from malicious traffic |
| DDoS filtering | Which traffic is forwarded or discarded under the agreed protection policy | Set global path selection and site distribution |
| Capacity planning | What load links, routers, filters and applications must handle at each site | Balance traffic without measurement or headroom |
Why anycast is not a precise global load balancer
RFC 4786 explicitly describes load distribution among anycast nodes as typically uneven. BGP selects paths from routing information and policy. A node may therefore receive a large catchment while another site has spare resources. Being ‘topologically closer’ does not necessarily mean lower round-trip time either. Capacity must be planned per site and for plausible shifts, not only as the sum of all nodes.
Anycast is not round-robin DNS
With anycast, the service address stays the same and routing selects the node. DNS-based distribution instead returns different addresses or answers. Both approaches can be combined, but their switching times, state and failure modes differ.
How anycast can help during an attack
Distributed nodes can absorb attack traffic from different source regions at different points. RFC 4786 lists localising non-distributed attacks and constraining distributed attacks or flash crowds to regions as potential goals. The work of separating legitimate and malicious traffic can also be spread across nodes. This is a scaling benefit—but only if the affected sites can actually transport, inspect and filter the incoming traffic.
RFC 4732: denial-of-service risks and partial mitigations
Illustrative scenario: three nodes, three catchments
The following example uses documentation values only: service address 192.0.2.53 is announced by nodes North, West and South. Users and attackers reach one of these nodes depending on routing. It is neither a real AS51202 route nor a statement of confirmed sites, capacities or operator policy.
| Event | Possible routing effect | Required protection decision |
|---|---|---|
| Attack from several networks | Sources may land in different catchments | Every affected node needs suitable filters and headroom |
| West withdraws its route | Its traffic moves to North or South after convergence | First verify that the remaining nodes can absorb the shift |
| The application fails only at South | Without a coupled health check, the route may remain visible | Treat service health, routing and fallback logic together |
The example shows why one global capacity total says little by itself. What matters is which sources reach which node, where bottlenecks sit and what happens when a catchment moves under load.
Route withdrawal can move the attack
A route withdrawal removes a node from path selection but does not remove the traffic. RFC 7094 warns against simply withdrawing an affected node's anycast route during a sustained DoS attack: the attack may move to the next node and trigger a cascade. The decision therefore needs thresholds, hold times, remaining capacity and a clear fallback plan. Repeated rapid announcements and withdrawals can also create routing instability.
RFC 7094: architectural limits and DDoS effects of IP anycast
- Before withdrawing, determine which catchments are likely to move to which remaining nodes.
- Do not react to link utilisation alone: the application, filters, routers and upstream may have different bottlenecks.
- Use a minimum hold time and controlled re-advertisement so that an unstable service does not cause route flaps.
- Define manual intervention and a stop point in case automation merely forwards the attack to another node.
A visible route does not mean a healthy service
A BGP neighbour can remain stable while the application, a local load balancer or the filtering path has failed. RFC 4786 therefore recommends coupling service availability to routing information, while also noting the complexity when one prefix covers several services. The health check must represent the function users actually need and must not toggle a global route for every short measurement failure.
Test long sessions and stateful systems separately
If the selected anycast node changes during an established connection, the new node often lacks the existing session state. This can interrupt TCP connections; NAT, stateful firewalls and application sessions also need a deliberate design. Short independent requests behave differently from downloads, streams, VPNs or other long-lived connections. Anycast does not synchronise that state automatically.
Plan capacity and filtering per node
- Ingress: the port, upstream and router must carry traffic as far as the filtering stage.
- Packet processing: consider Gbps and packets per second separately; small packets affect systems differently from large ones.
- Mitigation: profiles, rules and exception traffic must be sufficiently consistent at every node for the service.
- Application: even clean residual traffic can overload backends, TLS endpoints, DNS or databases.
- Failure headroom: calculate loss of a node and the resulting catchment shift as a separate scenario.
The confirmed AS51202 DDoS properties apply independently of this anycast principle: inbound traffic is filtered asymmetrically, automated profiling captures legitimate behaviour and adaptive threshold learning uses 95% of legitimate traffic as its learning baseline. Learning pauses during an attack while filtering remains active. None of this implies an anycast feature or guaranteed protection for every architecture.
Monitoring needs several viewpoints
- Service probes from several representative networks, because different sources may see different nodes.
- A node identifier in responses or logs so that failures can be attributed to a particular site.
- A routing view per region: advertised prefixes, AS paths, changes and unexpected origin ASNs.
- Separate per-node values for traffic, packet rate, filtering events, loss, latency and application health.
- One shared timeline for routing, mitigation and application events so that cause and effect are not reversed.
Acceptance before production
- 1From several networks, record which node answers over IPv4 and IPv6 and how that node is identified.
- 2Simulate a service failure without a link failure and verify that health checks and routing react as intended.
- 3Perform a controlled route withdrawal, observe convergence and session interruption, and measure the traffic shift.
- 4Check filtering with legitimate test traffic and authorised load tests only; never generate attack traffic without permission.
- 5Document node return, minimum hold time, alerts and manual rollback.
What to include in a protection enquiry
Provide services and protocols, IPv4 and IPv6 prefixes, current origin ASNs, existing anycast nodes, upstreams and expected catchments. Add normal bandwidth and packet rate per site, legitimate peaks, stateful components, desired failure behaviour and available telemetry. For an AS51202 enquiry, also include the handoff site, port, commit and preferred protection tier. This separates the job of routing from the filtering, capacity and application measures that remain necessary.