Your firewall can't stop a DDoS: the latest record hit 31.4 Tbps. Real mitigation happens upstream

There's a line we hear a lot whenever DDoS comes up: "relax, we have a good firewall". And there's a number that flattens it instantly: in December 2025, Cloudflare mitigated the largest DDoS attack on record, 31.4 terabits per second. That's roughly 31,000 times the capacity of a 1 Gbps business fibre. You don't even need a record: an attack a thousand times smaller is still 30 times your link. Your firewall can be excellent; it doesn't matter. By the time attack traffic reaches your firewall, the battle is already lost, because your access link filled up a few kilometres earlier. A volumetric DDoS isn't won on your premises: it's won upstream. That's what this post is about: how it's actually done, with BGP and a technique called RTBH, and what a network operator can do for you that no box in your rack ever will.

The myth: "the box stops it"

The misunderstanding comes from mixing up two different things. A firewall, an IPS or an anti-DDoS appliance works at the destination: it inspects traffic that has already reached you and decides what gets through. Against application-layer attacks —malicious HTTP requests, API abuse, low-bandwidth layer 7 floods— that makes sense and it works. But a volumetric DDoS isn't trying to sneak through your door: it's trying to fill the street. Its target isn't your server, it's your access link. And the link saturates on the stretch between your provider's network and your router — a stretch where your firewall hasn't seen a single packet yet. Dropping that traffic on arrival is like posting a bouncer at the door of a bar whose street is already jammed by a crowd: the bouncer does his job perfectly and the bar stays empty, because legitimate customers can't get anywhere near it.

There's a more sophisticated variant of the same mistake: the local blackhole. "I'll add a null route on my edge router and drop traffic to the attacked IP." We've seen it configured with the best of intentions, and it doesn't do what people think it does: the drop happens at your router, so the full volume of the attack still travels down your access link to reach it. We know this from operator experience: a local blackhole does not save your link. The packet has to be discarded where there's still capacity to spare: in the provider's core, or further up.

The 2025 numbers, to size the problem

According to Cloudflare's Q4 2025 DDoS report, in 2025 they mitigated 47.1 million DDoS attacks, up 121% on the previous year: an average of more than 5,000 attacks per hour, on their network alone. Size records fell like dominoes: 7.3 Tbps in May, 11.5 in September, 22.2 three weeks later and 31.4 Tbps in December. Behind the record sits the Aisuru-Kimwolf botnet, which has grown from more than 300,000 infected devices to an estimated 1 to 4 million —mostly Android TVs, IP cameras and home routers—. In December it launched a campaign of 902 attacks against Cloudflare and its customers, peaking at 24 Tbps and 205 million requests per second.

What RTBH is: dropping the attack where there's still room

RTBH (Remotely Triggered Black Hole) is the operators' classic tool for this, and it has worked for two decades. It's described in IETF RFC 3882 and RFC 5635, and the idea is elegant in its simplicity: instead of dropping the traffic at your router, you ask your provider to drop it at theirs. The mechanism is a BGP announcement. When one of your IPs is under attack, you announce that specific address (a /32 in IPv4) to your provider tagged with a special BGP community —there's a standardised one, BLACKHOLE, 65535:666, defined in RFC 7999—. On seeing that tag, the provider routes all traffic towards that IP into a black hole inside its own network: in the core, at its edges, where links run at hundreds of gigabits or terabits and the attack fits without breaking a sweat. None of that volume reaches your access link any more. The street is clear again.

And now the part almost nobody mentions, which we prefer to say out loud: RTBH completes the attack against the targeted IP. Once you announce the blackhole, that address stops receiving traffic — all of it, legitimate included. It's a triage decision: you sacrifice the service that was already down de facto so that the rest of your network —email, the ERP, the sales team's VPN, the fifty other things hanging off the same link— keeps working. That's why RTBH shines when the attack targets one IP and you have others to protect, and why prior design matters: separate services onto different IPs, know which ones are expendable and which aren't, and have the procedure rehearsed before you need it.

What if the attacked IP is precisely the one that can't go down? Then RTBH isn't your tool, and you climb a step: BGP Flowspec (RFC 8955) lets you ask the provider for finer-grained filtering —dropping only UDP to a given port, rate-limiting a specific pattern— though not every operator offers it to customers; and for critical public services, the answer is usually to put them behind an anycast network or a scrubbing service built to absorb these volumes. Each step up has its cost and its complexity. The honest thing to say is that none of these decisions is made well during the attack: they're made beforehand, with a cool head and the service map on the table.

How we do it

At everyWAN this isn't textbook theory: we're an operator with our own network —BGP, transit and peering, with a public looking glass at lg.everywan.com for anyone curious— and we run RTBH in our core. The other half of the equation, the one usually forgotten, is detection: you can't trigger a blackhole against an attack you can't see. We analyse traffic with NetFlow, which shows us in near real time which IP is receiving an anomalous volume, of what kind and from where — the difference between finding out from your graphs or finding out because a customer calls with everything down. NetFlow detection, a decision made with the service map in front of you, an RTBH announcement upstream: that's the full sequence, and all three links have to exist before the first attack.

Five questions to know if you're prepared

All of this is, at bottom, the same lesson we told with the AWS CloudFront outage: the decisions that save a bad day are made before the bad day. At everyWAN we design and operate business networks and communications with this operator mindset: BGP connectivity and redundancy where it belongs, NetFlow visibility, and DDoS mitigation agreed upstream rather than promised in a brochure. If you don't know how your provider would answer question 2, let's talk — it's a half-hour conversation that's far more welcome before the first attack than after.

In short

A volumetric DDoS doesn't attack your server: it attacks your link, and the link can't be defended from the inside. The firewall is still needed for its own job, but against sheer volume the only real defence is upstream, in networks with the capacity to absorb it and throw it away: RTBH to sacrifice one IP and save the rest, Flowspec or scrubbing when you need a scalpel instead of a hammer. The 2025 records —31.4 Tbps, 47 million attacks, 35-second bursts— don't change this logic: they confirm it with ever fatter numbers. The question isn't whether your firewall is good. It's whether your operator knows what to do when you announce a /32 tagged 65535:666 — and whether you know when to announce it.

Sources (verified): 2025 figures (47.1 million attacks mitigated, +121% year over year, 31.4 Tbps December record lasting 35 seconds, Aisuru-Kimwolf botnet of 1–4 million devices, December campaign of 902 attacks peaking at 24 Tbps / 205 Mrps) — Cloudflare, Q4 2025 DDoS report and CyberInsider; the 22.2 Tbps / 10.6 Bpps, 40-second attack (September 2025) and earlier Aisuru data (300,000+ devices per XLab) — BleepingComputer; the RTBH technique and BLACKHOLE community — RFC 5635, RFC 7999 and RFC 8955 (IETF). The RTBH, NetFlow and BGP operational experience described is from everyWAN's own network.