Scrubbing is the control that pulls attack traffic off the wire upstream, before it reaches the origin it is meant to protect. Whether it still does so under the volume and packet rate of a real flood is what a DDoS test measures. A scrubbing center is the infrastructure that performs it: a high-capacity facility sitting in the path between the public internet and a protected origin, where attack packets are filtered out and only clean traffic is forwarded on.
How diversion and filtering work
A scrubbing center does two separate jobs, and they fail for different reasons. The first is diversion: getting the traffic to route through the facility at all. On-demand scrubbing announces a change only once an attack is detected, either a BGP route announcement that pulls the target prefix toward the scrubbing network, or a DNS change that repoints the hostname at a scrubbing IP. Always-on scrubbing skips that step by keeping traffic in the path continuously, trading a little steady-state latency for zero cut-over delay.
The second job is the filtering itself. Inside the facility, traffic passes through layers that each shed a different class of attack: coarse volumetric drops for obviously malformed or reflected packets, flow and rate analysis for floods, and deeper inspection for application-layer patterns that survive the earlier passes. What comes out the far side is forwarded to the origin over a pre-established path, typically a GRE tunnel or a private cross-connect, so the cleaned traffic arrives without re-exposing the origin address.
The return path is its own piece of engineering. Because inbound traffic is diverted but replies from the origin often take the normal route back to the user, the flow becomes asymmetric, and the scrubbing relationship has to be built to tolerate that. It is also why always-on scrubbing costs a small, permanent latency tax: every packet takes the longer path through the facility even when nothing is attacking, in exchange for having no cut-over to wait on when something does.
Why it matters under attack
The headline number for a scrubbing center is aggregate capacity: the bandwidth in terabits per second and the packet rate in packets per second it can absorb before clean traffic starts degrading alongside the attack. But capacity is rarely the property that fails first in a real incident.
The cut-over is. On an on-demand model there is a window between the moment an attack is detected and the moment traffic is actually flowing through the facility, because a route or DNS change takes time to propagate. During that window the origin is still receiving traffic directly, and an attacker who watches for the diversion can time a burst to land inside it. A related trap is the return path: if cleaned traffic reaches the origin but the origin can still be reached from anywhere else, an attacker who knows the raw address simply routes around the scrubber entirely, which is the origin IP exposure problem. Scrubbing only works if the origin accepts traffic exclusively from the scrubbing network.
What a DDoS test measures
A test exercises each of those failure points rather than trusting the datasheet. It measures absorption capacity, the point at which offered attack volume begins to cost legitimate traffic, which is almost always lower than the advertised aggregate because a single customer prefix does not get the whole facility. It measures the detection-to-diversion interval, the real time to mitigation from the first abnormal packet to traffic flowing through the scrubber, and it probes the mitigation cutover window for how much reaches the origin before diversion completes.
It also confirms the lockdown. A test drives traffic straight at the origin address, bypassing the scrubbing path, to prove the origin refuses everything that did not arrive from the scrubbing network. If it answers, the whole investment is optional from the attacker's point of view. What that means for whether always-on or on-demand scrubbing is the right posture, and how to prove the cut-over actually holds, is worked through in DDoS protection in the path.