How DDoS Mitigation Works: Scrubbing, BGP Diversion, Anycast, and What Network Operators Should Prepare

DDoS mitigation is the set of techniques used to keep services online during a distributed denial-of-service attack — by absorbing, diverting, filtering, or discarding attack traffic before it overwhelms the target. Detection tells you an attack is happening; mitigation is what keeps customers connected while it does.

Most explanations of DDoS focus on the attack side: the types, the botnets, the traffic volumes. We cover that ground in our guide to the different types of DDoS attacks. This article covers the other side — what actually happens when a network defends itself, and what a business needs to have in place before an attack for those defenses to work.

One point shapes everything that follows: serious DDoS mitigation is largely a routing operation. Scrubbing centers receive traffic because a prefix’s BGP announcement is redirected to them. Blackholing works by announcing a route that discards traffic to a targeted address. Anycast absorbs attacks by announcing the same prefix from many locations at once. Because these techniques operate on announcements, a business’s mitigation options depend on how it holds and announces its IP address space — a dependency usually discovered during the first serious attack, which is the most expensive possible time to learn it.

What Is DDoS Mitigation?

DDoS mitigation is the process of protecting a target from distributed denial-of-service attacks by filtering out malicious traffic while allowing legitimate traffic through. The goal is not to make the attack stop — attackers control that — but to make it ineffective: services stay reachable, customers stay connected, and the attack traffic is absorbed or discarded somewhere it cannot cause harm.

Mitigation can happen at several places along the path between attacker and target: inside the target’s own network, at the target’s upstream providers, at a dedicated scrubbing facility, or distributed across a global anycast network. Where the mitigation happens matters enormously, because of a simple physical constraint: traffic must be stopped before it fills a link, not after. A volumetric attack larger than your Internet connection cannot be filtered by any device sitting behind that connection — the link is already saturated by the time the packets reach your equipment. This single constraint explains most of the architecture of modern DDoS defense.

The Four Stages of DDoS Mitigation

Effective mitigation follows four stages: detection, diversion, filtering, and return of clean traffic.

1. Detection. Monitoring systems identify that traffic toward a target deviates from its baseline — sudden volume spikes, unusual protocol mixes, abnormal connection patterns. Detection speed matters: the gap between attack start and mitigation activation is the outage window.
2. Diversion. Traffic destined for the target is redirected to wherever the filtering will happen. In on-demand scrubbing models, this is typically done by changing BGP announcements so the protected prefix routes through the scrubbing provider. In always-on and anycast models, traffic already flows through the protection layer, so no diversion step is needed.
3. Filtering (scrubbing). The mitigation layer separates attack traffic from legitimate traffic using signatures, rate limits, protocol validation, challenge mechanisms, and behavioral analysis. Volumetric floods are dropped in bulk; more subtle application-layer attacks require finer inspection.
4. Return of clean traffic. Legitimate traffic is forwarded on to the real infrastructure, commonly through a tunnel or private interconnect back to the origin, so services continue operating behind the shield.

Different techniques implement these stages differently — which is where the real decisions lie.

DDoS Mitigation Techniques Compared

1. Upstream and ISP filtering

The simplest option: your transit provider or ISP filters attack traffic before it reaches your link. Many providers offer basic protection — rate limiting, filtering of obviously malformed traffic — and some sell managed DDoS protection as an add-on. The strength of this approach is position: the provider sits upstream of your connection, so it can stop volumetric traffic before your link saturates. The limitation is depth and control: basic provider filtering is often coarse, activation may require a support ticket, and you are limited to whatever that one provider offers.

2. Scrubbing centers and BGP diversion

A scrubbing center is a high-capacity facility built specifically to absorb and filter attack traffic. In the common on-demand model, the protected business (or its provider) withdraws or adjusts the normal BGP announcement for the targeted prefix and the scrubbing provider announces it instead — usually as a more specific route, which the Internet’s routing system prefers. All traffic for that prefix, attack and legitimate alike, now flows to the scrubbing facility, which filters it and returns clean traffic to the origin through a tunnel (commonly GRE) or a direct interconnect.

This is where the routing dependency becomes concrete: diverting a prefix to a scrubbing center requires the authority to change how that prefix is announced. The scrubbing provider must be authorized to announce your space — which involves the same LOA, ROA, and route-object machinery described in our guide to how BGP works. If the RPKI ROA for your prefix names only your origin ASN, the scrubbing provider’s emergency announcement may be rejected by networks enforcing origin validation — so protection arrangements need to be reflected in routing records before the attack, not during it.

3. Remotely Triggered Blackhole (RTBH)

RTBH is the bluntest instrument in the toolkit: the network announces a special route that tells upstream providers to discard all traffic destined for a specific address. The attack traffic disappears — and so does all legitimate traffic to that address. RTBH deliberately completes the attacker’s goal for one address in order to protect everything else: the targeted address goes dark, but the link is no longer saturated and every other service on the network stays up.

RTBH makes sense when one address is targeted and the collateral saturation threatens the whole network. Its usefulness depends on granularity: blackholing a single /32 out of a /24 you control preserves 255 other addresses; if your provider can only blackhole at coarser granularity, or the targeted address hosts your only public service, RTBH is simply a self-inflicted outage. Operators with address headroom sometimes move a targeted service to a different address within their block and blackhole the old one — an option that exists only when you have spare, controllable address space.

4. Anycast absorption

Anycast announces the same IP prefix from many locations around the world. Traffic — including attack traffic — is routed to the nearest announcement point, so a globally distributed attack is automatically divided among dozens of sites instead of concentrating on one. No single location receives the full attack volume, and each site filters its share. This is the architecture behind the largest commercial DDoS protection networks and much of the global DNS infrastructure. Its precondition is structural: anycast requires a prefix that can be announced from multiple locations — either your own portable space announced from your own distributed presence, or (far more commonly) services fronted by a provider whose anycast network does this for you.

5. CDN and reverse-proxy protection

For websites and HTTP APIs, putting a CDN or reverse-proxy service in front of the origin provides substantial DDoS protection as a side effect: the provider’s anycast edge absorbs volumetric attacks, and its application layer filters HTTP floods. The critical limitation is scope — this protects the traffic that flows through the proxy, which means HTTP(S). Mail servers, VPN gateways, game servers, DNS resolvers, and any non-HTTP service remain exposed on their real addresses. A second common failure: if the origin’s real IP address is discoverable (old DNS records, mail headers, careless configuration), attackers bypass the proxy and hit the origin directly. Proxy-based protection is only as good as the secrecy and filtering around the origin address.

6. On-premises appliances

Dedicated mitigation hardware inside your own network can inspect traffic at line rate, handle application-layer attacks with full knowledge of your services, and react instantly without third-party involvement. What it cannot do is defeat a volumetric attack larger than your upstream link — the physics problem from earlier. On-premises equipment is therefore a complement to upstream capacity, not a substitute for it: it excels against protocol and application-layer attacks that fit within your bandwidth, and pairs naturally with cloud scrubbing for everything larger (a combination often sold as “hybrid” mitigation).

Which Technique Handles Which Attack?

Technique	Best against	Weak against	What it requires
Upstream/ISP filtering	Volumetric floods (stopped before your link)	Application-layer attacks; anything needing fine-grained policy	Provider offering it; often ticket-based activation
Scrubbing center (BGP diversion)	Large volumetric and protocol attacks on any service type	Nothing inherently — but activation takes minutes and needs pre-arranged routing authority	Announceable prefix, authorization for provider announcements (LOA/ROA/route objects), return tunnel
RTBH (blackholing)	Saving the network when one address is targeted	Protecting the targeted service itself (it goes offline by design)	Provider support for blackhole announcements; address granularity and headroom
Anycast absorption	Distributed volumetric attacks (divided across sites)	Attacks concentrated near one site; requires global footprint	Multi-site announcement of the prefix — usually via a protection provider
CDN / reverse proxy	HTTP(S) floods and volumetric attacks on web properties	Non-HTTP services; origin-IP exposure bypasses it entirely	Proxyable service; strict origin-IP hygiene
On-premises appliance	Protocol and application-layer attacks within link capacity	Volumetric attacks exceeding upstream bandwidth	Capital investment; skilled operation; pairing with upstream capacity

In practice, resilient operators layer several of these: proxy or anycast protection for web properties, scrubbing arrangements for the rest of the prefix, RTBH as the emergency valve, and on-premises inspection for application-layer subtlety.

Why Your IP Holding Model Shapes Your Mitigation Options

Because mitigation operates on announcements, the party that controls a prefix’s announcements controls the mitigation options — and that party depends on how the business holds its IP space.

• Provider-assigned addresses. Your addresses belong to your hosting or connectivity provider’s blocks, announced under their ASN. Your mitigation menu is exactly what that provider offers: their filtering, their scrubbing partnerships, their blackhole policy, on their timeline. You cannot divert the prefix to a scrubbing service of your choice, because the announcement is not yours to redirect. If protection is inadequate, the remedy is changing providers — which means renumbering every service.
• Your own or leased prefixes, announced under your control. When the business announces its own space — owned or leased with proper routing authorization — the full menu opens. You can contract with any scrubbing provider and authorize their emergency announcements; request blackholing at /32 granularity through your upstreams; move a targeted service within your block; and change protection providers without touching a single service address. The prefix is the stable identity; the protection behind it becomes swappable.
• Leased space specifically. Everything above applies to leased prefixes with one addition: the routing authorization must genuinely support it. A lease that includes clear LOA arrangements, ROA cooperation, and responsive record updates — the structure a IPv4 leasing arrangement should provide supports scrubbing diversion and blackholing exactly as owned space does. A lease that delivers only addresses, with an unresponsive upstream chain, leaves the lessee unable to authorize emergency announcements when minutes matter. DDoS readiness is therefore another entry on the list of what to verify before leasing, alongside the reputation and deployment factors covered in our IPv4 leasing guide.

To keep the claim precise: no holding model prevents attacks, and none guarantees survival — attackers do not consult your registry records. What announcement control provides is options and speed: the ability to enact any mitigation strategy the market offers, rather than the subset one provider happens to sell.

Always-On vs On-Demand Protection

Always-on protection routes all traffic through the mitigation layer permanently; on-demand protection activates diversion only when an attack is detected. The trade-off is straightforward:

Factor	Always-on	On-demand
Time to mitigate	Immediate — traffic is already inside the protection layer	Minutes: detection, BGP change, propagation
Latency in peacetime	Small permanent overhead from the extra hop (often negligible on good networks)	None — normal routing until activation
Cost	Higher — capacity reserved continuously	Lower base cost; some plans charge per incident
Best for	Revenue-critical, frequently attacked, or latency-tolerant services	Services that can tolerate a short exposure window; cost-sensitive deployments

A reasonable decision rule: calculate what a ten-minute outage costs your business. If that number exceeds the annual price difference between the two models, always-on pays for itself the first time it matters.

Building a DDoS Response Plan

A response plan converts mitigation capability into mitigation speed. The technical arrangements above are necessary but not sufficient — during an attack, the bottleneck is usually human coordination. A workable plan fits on a few pages:

1. Baseline and thresholds. Document normal traffic levels per service, and the thresholds at which detection alerts and mitigation activates. Without a baseline, every anomaly is a debate.
2. Decision authority. Name who can order diversion to scrubbing, who can request a blackhole, and who informs customers — including at 3 a.m. on a weekend.
3. Contact runbook. Emergency contacts and authentication details for every upstream provider and the scrubbing service, verified quarterly. A mitigation contract with an unreachable activation desk is decoration.
4. Pre-authorized routing changes. LOAs on file with the scrubbing provider, ROAs that accommodate their announcements, route objects aligned — all confirmed before any attack, per the earlier section.
5. Service triage order. Which services are protected first, which addresses may be sacrificed via RTBH, and where services move if renumbering within the block becomes necessary.
6. Origin hygiene. For proxied services, a standing check that real origin addresses are not leaking through DNS history, mail headers, or subdomains.
7. Testing. An annual (minimum) activation test with the scrubbing provider — diversion, filtering, clean-traffic return — because the first real attack is the wrong moment to discover a misconfigured tunnel.
8. Post-incident review. After any attack: what was targeted, what worked, activation time, and what changes.

Limitations and Honest Caveats

Several truths that vendor marketing tends to soften:

• No mitigation is absolute. Record-setting attacks grow yearly, and a sufficiently large or novel attack can degrade any defense. The realistic goal is raising the attacker’s cost above their motivation, and shrinking outage windows from hours to minutes.
• Blackholing is a controlled loss, not a save. RTBH protects the network by abandoning the target. Plans that rely on it should acknowledge what is being given up.
• Scrubbing has false positives. Aggressive filtering during an attack can drop some legitimate users — particularly those behind unusual network configurations. Clean-traffic guarantees are statistical, not perfect.
• Application-layer attacks evade volumetric defenses. A low-and-slow HTTP attack can pass through a scrubbing center that is watching for floods. Layered inspection exists precisely because no single filter sees everything.
• Protection follows preparation. Nearly every capability in this article — diversion authority, blackhole granularity, tested tunnels, verified contacts — must exist before the attack. Mitigation arranged mid-incident happens at ticket-queue speed while services are down.

Practical Checklist

1. Know your link capacity and your normal traffic baseline per service.
2. Confirm what DDoS protection each upstream provider includes, and its activation process.
3. Decide the protection model per service class: proxy/anycast for web, scrubbing coverage for the rest, appliance if application-layer risk warrants it.
4. If using scrubbing: authorization documents filed, ROAs accommodating the provider’s announcements, return tunnel configured and tested.
5. Confirm blackhole support and granularity with every upstream.
6. For proxied services: verify the origin IP is not discoverable.
7. Write the response runbook — thresholds, decision authority, contacts — and test it annually.
8. When acquiring or leasing IPv4 space, verify the arrangement supports emergency announcement changes at the speed an attack demands.

Practical Note from i.lease

The pattern behind most painful DDoS incidents is not the absence of protection technology — the market offers plenty. It is that the routing preconditions for using that technology were never put in place. A business signs a scrubbing contract, files it away, and discovers during its first attack that the provider’s emergency announcement is being rejected because the ROA names only the business’s own ASN; or that the upstream needs a fresh LOA that takes hours to process; or that the leased block’s upstream chain cannot authorize anything quickly because nobody is sure who is entitled to ask.

Every one of those failures was checkable in advance, and all of them come down to the same question this site returns to often: who actually controls the announcements behind your addresses, and how fast can that control be exercised? Businesses that hold or lease their IPv4 space through arrangements with clear, responsive routing authority get to use the full mitigation market. Businesses that discover the gaps mid-attack pay for the lesson in downtime. If DDoS resilience is part of why you are structuring your address strategy — whether you Buy IPv4 addresses or lease them — make announcement flexibility an explicit requirement, not an assumption.

Final Thoughts

DDoS mitigation works by moving the fight to where the defender has capacity: upstream filters stop floods before links saturate, scrubbing centers absorb attacks that BGP diversion delivers to them, RTBH sacrifices one address to save the network, and anycast divides global attacks across global infrastructure. Each technique handles different attack classes, which is why serious defenses layer several of them — and why the comparison that matters is not “which product” but “which combination, activated how fast.”

The structural insight for infrastructure planning is that nearly all of it runs on announcements. The business that controls how its prefixes are announced — through ownership or through leasing arrangements with genuine routing authorization — can divert, blackhole, redistribute, and switch protection providers without renumbering anything. The business that cannot is limited to one provider’s menu and one provider’s clock. Attack traffic is the attacker’s decision; how many options you have when it arrives is yours, and it is decided long before the first packet of the flood.

Frequently Asked Questions

How does DDoS scrubbing work?

Traffic for the protected prefix is routed to a high-capacity scrubbing facility — typically by changing the prefix’s BGP announcement — where attack traffic is filtered out and legitimate traffic is forwarded to the real infrastructure through a tunnel or interconnect.

What is blackholing (RTBH) in DDoS defense?

Remotely Triggered Blackhole is an emergency measure where upstream providers are asked to discard all traffic to a targeted address. The targeted service goes offline by design, but the attack traffic stops saturating the network, protecting everything else.

Can a firewall stop a DDoS attack?

Only partially. A firewall can filter protocol and application-layer attacks that fit within your Internet link’s capacity, but it cannot stop a volumetric attack larger than the link — the connection is saturated before packets reach the firewall. Volumetric attacks must be stopped upstream.

Does a CDN protect against DDoS attacks?

For websites and HTTP APIs, substantially yes — the CDN’s distributed edge absorbs volumetric attacks and filters HTTP floods. It does not protect non-HTTP services, and it fails entirely if attackers discover the origin server’s real IP address and target it directly.

How fast can DDoS mitigation activate?

Always-on protection mitigates immediately because traffic already flows through it. On-demand scrubbing typically takes minutes: detection, the BGP announcement change, and route propagation. Arrangements requiring manual tickets or fresh authorizations can take much longer — which is why authorizations should exist in advance.

What is BGP diversion?

BGP diversion is redirecting traffic for a prefix by changing how it is announced — typically having a scrubbing provider announce the prefix (often as a more specific route) so the Internet routes all its traffic through the scrubbing facility during an attack.

Do I need my own IP space for DDoS protection?

No — proxy and CDN-based protection works with any addresses, and providers protect their own assigned space. However, announcing your own or properly leased prefixes gives you the full range of options: choosing your scrubbing provider, fine-grained blackholing, and switching protection services without renumbering.

Can leased IP addresses be protected against DDoS?

Yes, with the same techniques as owned space, provided the lease’s routing authorization genuinely supports it — the lessor and upstream chain must be able to authorize scrubbing announcements and blackhole requests quickly. This capability should be verified before leasing, not during an attack.

How long do DDoS attacks last?

Most attacks last minutes to hours, though sustained campaigns can continue for days with intermittent waves. Attack duration is the attacker’s choice; mitigation aims to make the duration irrelevant by keeping services online throughout.

What does DDoS protection cost?

It ranges from bundled basic filtering included with hosting and transit, through CDN plans, to dedicated always-on scrubbing contracts priced on clean-traffic volume and protected capacity. The practical comparison is protection cost against the revenue and reputation cost of your realistic outage window.

Also Read

• Understanding the Different Types of DDoS Attacks
• Difference Between DoS and DDoS Attacks
• What Is BGP? How Border Gateway Protocol Turns IP Addresses into Reachable Services
• What Is IP Spoofing and How Do Networks Defend Against It?