BGP Anycast and Network-Layer DDoS Absorption Architecture

Network-layer DDoS attacks jumped roughly 168% year-over-year in early 2026. The largest one on record, peaked at 31.4 Tbps and pulled its traffic from a large botnet of compromised devices. It got mitigated in 35 seconds. No engineer paged, no customer outage. That gap, between an attack big enough to make headlines and a response quiet enough that nobody notices, is the whole story: BGP anycast turns one overwhelming flood into hundreds of smaller streams absorbed locally, so the network's shape does the defending instead of some box sitting in front of it. The old model, buy a bigger pipe, bolt on a scrubbing appliance, still gets sold, but by 2026 it routinely loses to attacks that outsize the pipe on arrival. That's just Tuesday now.

What BGP anycast does to incoming traffic

Anycast runs on a simple trick: announce the same IP prefix from many locations at once, and let BGP sort out which location each packet actually reaches. No central traffic cop makes that call. Every network along the path picks whichever route looks best to it, and the packet lands wherever that decision leads.

A 100 Gbps attack aimed at an anycast address doesn't hit one wall. It splits across N walls, and each one only has to absorb a slice. That's the whole trick: the architecture spreads the blast radius instead of trying to armor a single point against the full weight of it.

The set of clients landing on a given site is called its catchment, and catchments are not evenly drawn. They follow BGP path selection, not geography or latency, which makes them lumpy and more than a little arbitrary. A measurement study of the B-Root nameserver found one site splitting traffic 82.6% to one location and 17.4% to another, nowhere close to even. That lumpiness looks like a flaw until it's the attacker's traffic getting scattered the same uneven way. No single site ever gets handed the full attack volume on a platter.

Google's global load balancer works this pattern at scale: a single external IP gets advertised from over 200 edge locations, user traffic enters at whichever edge is nearest, and from there it rides Google's private backbone instead of the open internet for most of the trip. The principle holds regardless of vendor. An operator doesn't need to out-muscle a botnet's total volume. It needs enough distributed sites that no single one ever sees the full load.

BGP's role in giving operators active control during an attack

Anycast is not a set-it-and-walk-away defense. Treating it like one is the mistake most operators make, right up until the attack that teaches them otherwise. Research on what's been called "Anycast Agility" (Rizvi, Bertholdo, Ceron, and Heidemann) lays out how operators steer traffic mid-attack: shift load toward sites with spare capacity, or deliberately concentrate the attackers onto a few sites to keep the rest running clean.

Think of it as a playbook with uneven tools. AS prepending works almost everywhere. Community strings and path poisoning get filtered inconsistently, especially by Tier-1 networks, so which lever actually works depends on the topology an operator happens to be sitting inside, and finding that out mid-attack is too late.

Pulling the right lever also means knowing how big the attack actually is, which sounds obvious until packet loss is happening upstream of the defender and the numbers on hand are already wrong. The Anycast Agility research proposes a method for estimating true offered load even under that condition, because guessing wrong means picking the wrong response, and there's no partial credit mid-attack.

Remote Triggered Black Hole routing is the blunt instrument here. It makes the victim's IP completely unreachable, trading total availability for total absorption. It works the way a car crusher works. BGP Flowspec (RFC 8955 for IPv4, RFC 8956 for IPv6) is the scalpel instead: it encodes filtering and rate-limiting rules as entries distributed across the network through BGP's multiprotocol extensions, SAFI 133 for unicast and SAFI 134 for Layer-3 VPN traffic, with nobody touching individual router configs by hand.

Even spotting scrubbing in progress is its own measurement problem. Research presented at PAM 2026 classifies a prefix as scrubbing-protected when it temporarily shifts origin or upstream in BGP update data. One documented case: prefix 46.184.90.0/24 was originated by Vercara between 13:17 and 13:39 on May 10, 2025, against its normal origin of AS 48695. That signature lets outside observers measure scrubbing adoption across the internet without needing operators to self-report anything.

None of this gets figured out live. These levers work because they get tested and rehearsed ahead of time. An attack is the worst possible moment to read documentation for the first time.

RPKI as the routing integrity foundation that makes anycast defenses trustworthy

Anycast's routes provide no defense if they aren't legitimately announced. BGP hijacks cause outages and security breaches on their own, DDoS aside, and an anycast defense sitting on top of a hijacked prefix is a liability wearing a defense's clothes.

RPKI, Resource Public Key Infrastructure, exists to close that gap. It lets operators drop invalid routes from peers using Route Origin Authorizations, so traffic goes where it's supposed to instead of wherever a forged announcement points it. Adoption is climbing but still partial: as of April 2025, NIST data put certified prefixes above 55% of the internet, with just under 30% of networks actually validating the BGP announcements they receive. That gap between certified and validated is the number that matters, because a signed route nobody checks protects nothing. The White House's routing security roadmap, published in September 2024, names RPKI a critical piece of internet routing security, which makes that gap a policy failure now, not just an engineering one.

Enforcing route origin validation on ingress means an operator will occasionally reject traffic to a network with a misconfigured route origin authorization record, breaking reachability that would otherwise work. That's a deliberate trade, not an oversight: it prioritizes routing integrity over universal reachability, on the logic that a distributed anycast network is worthless if the announcements defining its catchments can be forged.

Network capacity as DDoS budget in a production anycast deployment

Total capacity minus a normal day's peak utilization equals the headroom available to absorb an attack without anyone noticing. Call it a DDoS budget. Scale here is not a marketing word but an actual number on a spreadsheet, because the wider that gap, the bigger an attack a network can shrug off.

At the large end, some networks have recently crossed 500 Tbps of external capacity spread across more than 330 cities. Peak daily utilization on a network that size is a sliver of the total, and that unused sliver is the budget. Running the record 31.4 Tbps attack against 500 Tbps of distributed capacity makes that event, geometrically speaking, a rounding error. It gets absorbed because it's chopped up across hundreds of sites, each handling a chunk it can actually chew.

The October 2024 incident tells the same story at a different scale: a Mirai-variant attack, 5.6 Tbps, roughly 13,000 compromised IoT devices and routers, lasting 80 seconds. Each point of presence absorbed a portion of it, malicious traffic got flagged within seconds and dropped at the edge before it ever reached a customer's origin server. No outage, no drama.

The same geometry holds at a fraction of that scale, and it's a mistake to assume this playbook needs Google's budget to work. Sharktech runs an anycast deployment across five data centers, Los Angeles, Las Vegas, Denver, Chicago, and Amsterdam, with roughly 1.1 Tbps of aggregate connectivity. Its 100G DDoS Protection add-on assigns anycast IPs announced from all five sites via BGP, with GRE tunnels handling the return path. Different order of magnitude, same underlying math: what matters is the ratio between total distributed capacity and whatever slice any one site will realistically face, not the raw size of the network.

How packets are dropped at line rate before the network stack sees them

Absorbing traffic at a point of presence only counts if that POP can drop the garbage fast enough to protect everything behind it. A POP whose CPU gets pinned by attack traffic is just failing more slowly than a total outage would.

XDP, eXpress Data Path, hooks packets the moment they arrive at the network card and runs them through a chain of programs that decide what to drop before the traffic ever touches the Linux network stack. Applications downstream never even know the attack happened. eBPF, extended Berkeley Packet Filter, is what makes those mitigation rules programmable at the driver level, evaluated per packet. Purpose-built drop programs sit early in that chain, and the whole approach skips the kernel overhead that normal packet processing would otherwise carry.

Splitting an attack across hundreds of sites only works if each site can process its slice at multi-hundred-Gbps line rates without falling over. That's the exact job XDP and eBPF are built for, and it's why the split-the-load idea from the first section holds up under real load instead of just sounding good on a whiteboard.

One reported day saw over 5,000 attacks blocked in automated fashion. Anycast distribution plus automated eBPF drop rules finishes mitigation faster than a human could read the alert, let alone respond to it. The architecture is the operator, full stop.

Hardware density drives the trend from here. Newer server chips, high-core-count AMD EPYC Turin CPUs among them, trade some L3 cache for raw compute density and roughly double throughput per unit. More cores at each site means more packets processed in parallel, and that's the physical floor everything above it stands on.

The shift from volumetric attacks to Layer 7

Everything above assumes the attack is a volume problem: too many packets, not enough pipe. Layer 7 attacks break that assumption. HTTP/2 Rapid Reset (CVE-2023-44487) ran at a few hundred Mbps, laughably small next to a 31 Tbps flood, and still devastated targets by opening huge numbers of HTTP/2 streams and immediately sending RST_STREAM on each one. Servers allocate state per stream, the resets pile up faster than the state can clear, and CPU exhausts. The attack peaked at roughly 400 million requests per second in October 2023.

Anycast distribution does not solve this the way it solves volumetric floods, and assuming otherwise is how operators get blindsided. Splitting the load across sites still helps in that each POP sees a smaller slice of requests. But if every one of those requests looks like a valid HTTP call, the application layer at each site still has to process it. Distribution cuts volume per site. It cannot tell a real user from an attacker, and that's the whole limit of the architecture right there.

APIs have become the preferred target inside this shift, and the numbers back it up without needing decoration. Indusface's State of Application Security report found APIs got hit 675% harder than traditional websites. DataDome's 2025 Global Bot Security Report found 64% of AI bot traffic that year hit form pages, 23% hit login endpoints, and 5% made it to checkout, a funnel that looks uncomfortably like a real user's path through a site. Telling that traffic apart from an attack takes behavioral signals working together: verified bot IP ranges, TLS fingerprinting, behavioral analysis, robots.txt compliance. No single signal carries the load alone.

The gap here is bigger than most WAF vendors want to admit. DataDome's report found only 2.8% of websites fully protected against bot attacks in 2025, down from 8.4% in 2024, with over 61% completely unprotected. A WAF on its own cannot tell whether a visitor is a person or a script, and no amount of signature tuning fixes that, because the traffic is well-formed. It's just lying about who's sending it. That's why the category widened into WAAP, web application and API protection, bolting bot management and API security onto the WAF and pairing the whole thing with DDoS mitigation. The anycast network handles the volumetric flood. Behavioral analytics handles what survives it.

Evaluating WAAP platforms that pair L7 detection with anycast-backed absorption

Two evaluation frameworks come up repeatedly in this space: Forrester's Wave for Q1 2025, and SecureIQLab's Cloud WAAP v4.0 report. Both assess overlapping sets of vendors, which makes cross-referencing them worth the effort instead of redundant.

Imperva appears prominently in both evaluations, earning a Secure by Default rating from SecureIQLab. Its platform folds Cloud WAF, Advanced Bot Protection, API Security, DDoS Protection, Client-Side Protection, Account Takeover Protection, and CDN into one stack, and SecureIQLab's testing recorded 100% results in bot defense, Layer 7 DoS, and false-positive avoidance: a clean sweep across three categories that usually trade off against each other.

Akamai also appears prominently in both evaluations, running WAAP from one of the largest edge networks in operation. SecureIQLab's cloud-based deployment testing assessed its security and operational efficiency against the group average. The evaluations noted areas where Akamai's integrations leave room for improvement.

The broader SecureIQLab field landed around the group mean overall, with the top performers blocking all bot and Layer 7 DoS attack types thrown at them and avoiding nearly all false positives in their respective configurations. Where the field showed real variance was API coverage, with uneven results across different protocol types and a common web-application protocol and a persistent-connection protocol came in notably weaker across tested configurations, so that specific gap needs checking against whatever API protocols a given deployment actually runs.

A network running 500 Tbps of aggregate capacity across more than 330 cities, reaching 95% of the world's internet-connected population within 50 milliseconds, is the catchment geometry from earlier built at real scale instead of sketched on a whiteboard. It's why a record-setting volumetric attack turns into a non-event instead of a front-page outage. Pricing follows the same logic: consumption-based pricing beats flat capacity fees, because clean traffic and idle capacity shouldn't cost anything, and DDoS mitigation belongs at every pricing tier, free included, since the attack never checks anyone's invoice before it arrives.