How to Build a DDoS Test Lab, and the Acceptance Criteria to Use in It

Two things make a DDoS test lab different from an ordinary one. The traffic it generates is indistinguishable from an attack if any of it escapes, and the property being measured — the point at which something stops coping — can only be found by pushing past it.

Both argue for the same thing: a genuinely closed environment, built once, in which a run can be repeated exactly.

At a glance

Appliance	Lab element	Minimum viable	What it buys you
Isolation	Physically separate switching, no route to any production or public network	The only element with no acceptable compromise
Attack generation	One host able to saturate the link at small frame sizes	Packet rate, which is what actually stresses the device
Legitimate traffic	A scripted client completing a full business transaction	The measurement that decides whether mitigation worked
Measurement	Independent capture on both sides of the device	Results the vendor's own console cannot flatter
Time	One synchronised clock source for every element	Correlatable timelines across captures and logs

Only the first row is absolute. Everything else can start modest and improve, and a modest lab that runs reproducibly beats an expensive one that runs once.

Isolation, which is the only requirement with no flexibility

Attack traffic escaping a lab is an attack. It does not matter that it was unintended, and the addresses it carries will be yours.

Physical separation is the right answer wherever it is achievable: separate switching, no uplink to any production or public network, and no shared infrastructure with a management network that has a route out. VLAN separation on shared switching is common and is one configuration error away from failing.

No forwarding path, in both directions. The generator must not be able to reach anything outside, and nothing outside should be able to reach the target. The second half is skipped frequently and matters: a lab target running a vulnerable stack for testing purposes is exactly the thing you do not want reachable.

Address hygiene. Use documentation and private ranges throughout. Spoofed source addresses in a lab are essential for realistic testing and are precisely what must never reach a real network — a lab whose spoofed traffic escapes has performed a reflection attack on whoever owns the addresses it forged.

Out-of-band management. The path used to control the test must not be the path under test, because the interesting part of every run is where the tested path stops working.

Written authorisation, even for your own equipment on your own premises. The reasoning and the paperwork are covered in authorised DDoS testing, which should be read before the lab is built rather than before the first run.

Topology

Six elements. Only the first five are usually drawn, and the sixth is the one whose absence ruins results.

1. Attack generator. Its job is packet rate at small frame sizes, not bandwidth. Sizing it is the arithmetic in the capacity planner: a device rated for tens of millions of packets per second needs a generator that can reach that, which is a different purchase from one that can fill a link with large frames.

2. Legitimate traffic source. A scripted client performing complete business transactions throughout every run. Without this the lab measures only the attack, which is the mistake that makes drop percentages meaningless.

3. Device under test, configured as it would be in production. A device tested in its default posture has been tested as nobody will run it.

4. Target, resembling the protected service in the ways that matter: same protocol stack, comparable session behaviour, comparable resource limits. A target too robust to fail hides the effect; one too fragile fails before the device is stressed.

5. Measurement points on both sides of the device under test, capturing independently of it. This is the element that turns a demonstration into a measurement.

6. A synchronised clock. Every element on one NTP source, verified before each run. Correlating a capture, a device log and an application log across three unsynchronised clocks is an afternoon lost to arithmetic, every time.

Measurement discipline

Never let the device under test be the only witness. Every mitigation product counts what it did, and those counters are usually accurate and always self-interested. Independent capture on both sides settles it.

Measure the legitimate side continuously. Completion rate, latency distribution and time to first successful retry, sampled throughout each run rather than summarised at the end.

Record the frame-size distribution of what you generated. A result without it cannot be compared against a datasheet figure or against another product’s run.

Capture selectively. Full capture at high packet rates fills disks in minutes. Capture the legitimate flows in full and sample the attack traffic, and decide this before the run rather than during it.

Reproducibility

A run that cannot be repeated is an anecdote. The discipline is boring and non-negotiable:

• A written scenario definition: vectors, rates, ramp profile, duration, source count and distribution.
• Configuration captured as a file before and after every run, and diffed.
• Every run executed at least twice. Where the two disagree beyond the noise you established in the baseline, the cause is found before continuing.
• A run log recording what was changed between runs and why.

The run-twice rule catches more errors than any other single practice, and it is the one most often dropped when the schedule slips.

Scenario set

Start with a baseline of legitimate traffic and no attack, long enough to establish normal variance. Then, each with a ramp rather than an instant start:

• A volumetric flood at 64-byte frames, ramped past the rated capacity to find the ceiling.
• A session-exhaustion attack, which stresses new-session rate rather than bandwidth.
• An application-layer flood of well-formed requests at abnormal volume.
• A low-and-slow scenario, which stresses concurrency and timeouts and looks like nothing on a bandwidth graph.
• A multi-vector run combining the above, because the interaction is where products differ most.
• A pulse pattern of short repeated bursts, which tests detection latency rather than capacity.
• A degraded-dependency run with the device’s outbound path to its supplier blocked, for the reasons in what happens when the vendor cloud goes offline.
• A recovery period after each, measured, because late-clearing state shows up nowhere else.

The vectors themselves are described in the attack encyclopedia; this page assumes the mechanisms are understood and concerns itself with measuring them.

Acceptance criteria template

The criteria belong in the contract and the numbers belong to you. Anything printed here as a default would be a stranger setting your risk appetite, so the numbers are blank on purpose.

Criterion	Measured as	Threshold
Legitimate transaction completion under attack	% of pre-attack baseline, with sample size	≥ ___ %
Added latency, 95th percentile	Milliseconds above baseline	≤ ___ ms
Time to mitigation	Attack start to steady-state suppression	≤ ___ s
Sustained packet rate	pps at 64-byte frames, mitigation active	≥ ___ Mpps
New sessions per second	Sustained, without loss	≥ ___ /s
Longest refusal of a legitimate source	Seconds until an identical retry succeeds	≤ ___ s
Multi-vector behaviour	Completion rate during combined run	≥ ___ %
Degraded-dependency behaviour	Which functions continue, per function	Stated
Failover time	Bypass triggered to traffic flowing	≤ ___ ms
Recovery to baseline	Attack end to normal completion rate	≤ ___ s
Evidence export	Incident record in required format, unassisted	Pass/fail

Three rules for using it. Set every threshold before the first run, because a threshold chosen after a result is a justification. State the sample size beside every rate, since a percentage without a denominator is not a measurement. And record which criteria were measured versus contractually required, because the two carry very different weight when something fails in production.

What the lab still cannot tell you

It cannot tell you how the product behaves on your real traffic mix, with your real client population and its awkward tail. It cannot tell you what an operator will do at 3am. It cannot tell you what the supplier is like to work with in year three.

Those are established by replaying production traffic where that is possible, by running the incident runbook as an exercise with the people who would actually be on the call, and by talking to reference customers without the vendor in the room. The lab settles the technical questions, which is a large part of the decision and not the whole of it.