Itnetic TechnologiesWhat a scrubbing center actually is
A scrubbing center is a physical location — a cluster of filtering hardware and servers sitting behind very large upstream capacity — that traffic is routed through so attack packets can be discarded before they reach you. The plumbing metaphor is the whole idea: dirty water in, clean water out.
The term comes from the era when DDoS mitigation was somewhere you sent your traffic rather than something that happened everywhere at once. That history still shapes how the products are sold, so it is worth being precise about what the word does and does not tell you:
- It tells you where filtering happens: in a small number of large facilities, rather than at the edge nearest your visitors.
- It tells you nothing about how traffic is classified. A scrubbing center may do nothing more sophisticated than packet-rate thresholds, or it may run full request-level analysis.
- It tells you nothing about when your traffic goes through it — and that turns out to be the variable that decides whether you stay online.
Scrubbing is one implementation of the diversion and filtering stages described in what is DDoS mitigation. The rest of this guide is about the trade-offs that come with putting those stages in a central facility.
How traffic gets into a scrubbing center
Traffic does not wander into a scrubbing center on its own. Something has to redirect it, and there are three ways that happens.
| Diversion method | What it protects | What you need | Time to activate |
|---|---|---|---|
| BGP announcement | Every protocol and port on your prefix | Your own IP space (a /24 minimum to be routable), an ASN or a provider willing to announce for you, a GRE tunnel or cross-connect for the return path | Minutes, plus internet-wide convergence |
| DNS / reverse proxy | HTTP, HTTPS and whatever else the proxy speaks | Two DNS record changes | Minutes as records propagate |
| On-net / direct connect | Everything you host there | Your servers already live inside the provider's network | Immediate, by definition |
BGP diversion works by having the scrubbing provider announce your address block from their network, so the internet's routing table sends your traffic to them instead of you. Clean traffic then comes back to you over a tunnel — usually GRE — or a private cross-connect if you are in the same facility. This is the enterprise and ISP route. It protects game servers, VPN endpoints, mail and anything else that is not HTTP, but it requires portable address space and people who are comfortable with routing.
DNS diversion points your hostnames at the provider's edge instead. There is no routing work and no address space requirement, which is why it is the standard for websites and APIs. It only covers the protocols the proxy terminates, and it is only as good as your origin lockdown — see how to hide your origin IP address.
What happens inside the pipeline
| Stage | What it does |
|---|---|
| Telemetry | Sampled flow data (NetFlow, sFlow, IPFIX) is compared against a baseline of your normal traffic |
| Coarse filtering | Anti-spoofing checks, malformed and fragmented packets dropped, known reflection sources cut off — see DNS amplification |
| Protocol validation | SYN cookies and handshake validation so half-open connections never reach your connection table |
| Rate shaping | Per-protocol and per-source limits applied to what survives the earlier stages |
| Application inspection | Only if the center terminates TLS: request-level analysis, fingerprinting, challenges |
| Return path | Clean traffic forwarded to your origin over GRE, VXLAN or a cross-connect |
Note where the line falls. Everything above the "application inspection" row operates on packets and counters. It is extremely effective against volumetric and protocol floods, and it is blind to an attack made of well-formed HTTP requests.
The part vendors round down: time to mitigate
On-demand scrubbing sits idle until an attack is detected, then diverts. Every step in that sequence takes time:
| Step | Typical duration |
|---|---|
| Detection from sampled flow data | 30–90 seconds |
| Decision — automatic threshold, or a human on a bridge call | Seconds to several minutes |
| BGP announcement and internet-wide convergence | 1–5 minutes |
| Tunnel and session re-establishment | Seconds to minutes |
| Total before the first attack packet is dropped | Commonly 5–20 minutes |
Now compare that clock with the attack. Booted traffic is rented by the minute, and pulse-wave attacks deliberately arrive in short bursts that stop before mitigation engages and resume once it stands down. An attacker who knows you run on-demand scrubbing does not need to beat your filter — they only need to stay shorter than your activation window and repeat.
That is the practical case against on-demand anything: your provider measures success in minutes, your checkout measures failure in seconds.
Scrubbing centers vs. always-on edge filtering
| On-demand scrubbing center | Always-on edge filtering | |
|---|---|---|
| Normal traffic path | Straight to your origin | Already through the filter |
| Time to mitigate | Minutes of diversion and convergence | Effectively zero |
| Short bursts and pulse waves | Usually over before mitigation engages | Absorbed silently |
| Latency | Traffic hairpins to the nearest scrubbing facility, which may be nowhere near your visitors | Filtered at the point of presence closest to the visitor |
| Layer 7 coverage | Packet-level only, unless the center terminates TLS | Request-level behavioral analysis, continuously |
| Behavioral baseline | Cold start at the moment of diversion | Built continuously from your real traffic |
| Setup | Address space, BGP, tunnels | Two DNS records |
| Best fit | ISPs, hosting companies, non-HTTP protocols, large enterprises | Websites, APIs and game servers |
The two are not opposites. A modern edge network is a distributed scrubbing network — the same filtering work, spread across many small locations that are always in the path instead of a few large ones you are steered into. And volumetric absorption still happens upstream in both models, because gigabits have to be soaked up by a network with gigabits to spare.
What scrubbing alone will not catch
A packet-level scrubber is looking for volume and malformation. These attacks have neither:
- Layer 7 floods — every request is valid HTTP with a plausible user agent. A few thousand requests per second against search or checkout is a rounding error in packets per second and a catastrophe for your origin.
- Low-and-slow attacks — Slowloris and R.U.D.Y. exhaust connection slots with almost no traffic at all. They will not cross a volumetric threshold, ever.
- Cache-busting floods — randomized query strings turn every request into a cache miss and push the whole load onto your origin.
- Bots that look like customers — credential stuffing, scrapers, card testing. They are not trying to exceed a threshold; they are trying to look normal, and against a counter they succeed.
- Everything under the trigger — an attack sized just below your detection threshold never causes a diversion at all. It just makes your site slow.
Stopping these means classifying requests, not counting packets: behavioral baselines per endpoint, TLS and HTTP fingerprinting, rate limits keyed on something better than an IP address, and WAF rules — the division of labor in WAF vs DDoS protection.
Questions worth asking before you buy scrubbing
- Is it always-on or on-demand? If it is on-demand, ask what the measured time to mitigate is, and whether the SLA clock starts at the attack or at your ticket.
- Who triggers the diversion? An automatic threshold behaves very differently at 03:00 than a process that requires you to call someone.
- Does it terminate TLS? If not, no amount of scrubbing capacity will touch an application-layer flood.
- Where are the facilities relative to my users? Diverted traffic takes the long way round; that shows up as latency for every visitor, not just attackers.
- What does the return path look like? GRE tunnels add overhead and MTU headaches, and they are a single point of failure if there is only one.
- Is attack traffic billed to me? Being attacked should not generate an invoice — check this against the rest of what a DDoS attack costs.
- Can I prove what was dropped? Post-incident review needs per-request evidence, not a bandwidth graph.
Where Itnetic fits
We do not sell an on-demand scrubbing service, and we will not ask you to announce prefixes or terminate a GRE tunnel. The model is the other one: filtering that is already in the path before the attack starts.
Volumetric absorption happens upstream of our edge, where it belongs — Frankfurt and Beauharnois sit behind X4B, a network with 3 Tbps of capacity, and Singapore runs on OVHcloud with OVHcloud's own network-level protection. The full list is on the network page. Layer 7 filtering runs continuously at every point of presence, on a behavioral baseline built from your own traffic rather than a model that starts cold the moment someone declares an incident. Real visitors pass without CAPTCHAs, every block is written to per-request logs, and attack traffic is never metered against your bandwidth quota — see pricing.
Getting there is two DNS records and about five minutes: Itnetic's DDoS protection, free Starter plan included. If you want the mechanics of mitigation end to end first, start with what is DDoS mitigation.