An on-premise DDoS test answers one question the cloud posts cannot: when no managed edge is absorbing volume on your behalf, does your own diversion path engage fast enough, and does it hold?
It is not a test of whether your scrubbing provider can clean traffic. A reputable provider with hundreds of gigabits of capacity can. It is a test of whether the path into that capacity works under pressure: whether detection fires, whether the BGP announcement propagates, whether the clean-pipe return is configured correctly, and whether the gear at your perimeter survives the window before any of that converges.
This is the on-premise instance of structured DDoS testing. It is the one environment in the series with no public-cloud front end, which makes it the most revealing. On AWS, Azure, and GCP, a global anycast edge silently eats most volumetric traffic before your configuration is ever consulted. On-premise, that edge does not exist. You are the edge.
Everything a cloud platform makes automatic, you assemble yourself: transit headroom, a scrubbing relationship, BGP signaling, return-path routing, and the stateful devices at the boundary. Each piece is a hypothesis about resilience, and on-premise the hypotheses are coupled in ways that only fail together, under load, at 3 a.m.
That coupling is the reason on-premise testing matters more, not less, than its cloud siblings. The platform does not catch your mistakes for you.
At a glance: what an on-premise DDoS test validates
| On-premise control | What it is supposed to do | What the test actually verifies |
|---|---|---|
| Transit / upstream capacity | Carry legitimate load with headroom | The saturation ceiling: at what offered rate the access links fill before any mitigation engages |
| On-demand or always-on scrubbing | Divert and clean attack traffic upstream | Detection-to-divert interval, BGP convergence time, and whether the clean-pipe return actually carries scrubbed traffic back |
| RTBH / BGP Flowspec | Coarse and granular upstream drop | Whether the blackhole drops the target without taking out everything behind the same prefix; Flowspec rule propagation |
| Stateful perimeter (firewall, load balancer, appliance) | Enforce policy and absorb residual load | The connection-table ceiling: which device exhausts state first, and at what rate |
| Mitigation appliance | Drop attack traffic at the boundary | Throughput under line-rate load, and whether it fails open or closed when overwhelmed |
| Application tier | Serve real users | Behavior under the residual L7 load that survives every upstream control |
The recurring theme is the same as in the cloud, inverted. In the cloud, the resilience lives in how managed primitives are wired together. On-premise, you own both the primitives and the wiring, so a test characterizes the entire chain, including the seams the cloud would have hidden.
The protection surface you are testing
Before designing the test, be precise about each control. On-premise the controls are network-operator primitives, not managed services, and the test plan maps directly onto them.
Transit and the saturation ceiling
Your access links have a fixed capacity. That number, not your firewall's rated throughput, sets the first hard ceiling.
A volumetric flood that exceeds the sum of your transit does not need to defeat any device. It fills the pipe, and legitimate packets are dropped by congestion at the carrier's edge long before they reach anything you own. This is the failure mode the cloud platforms hide most completely, because their edge capacity is effectively unbounded from a single customer's perspective.
On-premise, the saturation ceiling is finite and knowable. The test's job is to establish where it sits relative to a realistic attack, and to confirm that the next control engages before it is reached.
Always-on versus on-demand scrubbing
Scrubbing is the upstream capacity that cleans attack traffic and returns the legitimate remainder. It comes in two postures, and the distinction governs the entire test.
Always-on scrubbing keeps your traffic flowing through the provider's cleaning infrastructure continuously. There is no diversion event because traffic never leaves the scrubbed path. The trade is a constant latency cost and a standing commercial commitment.
On-demand scrubbing keeps traffic on the direct path until an attack is detected, then diverts it. It avoids the steady-state latency penalty, but it introduces a window: the interval between attack onset and traffic actually flowing through the scrubber. That window is the single most important thing an on-premise test measures, and most estates run on-demand.
The divert itself is usually a scrubbing center relationship signaled over BGP.
BGP diversion and the clean-pipe return
On-demand diversion works by changing routing. When detection fires, you (or the provider) announce your prefix from the scrubbing center, so the internet's path to your address now leads through the scrubber first.
Two halves have to work. The divert half is the announcement and its propagation: a more-specific route, or a community-tagged advertisement, that pulls inbound traffic toward the scrubber. The return half is the clean-pipe path that carries scrubbed traffic from the provider back to your data center, typically a GRE tunnel or a dedicated cross-connect that bypasses the diversion so it does not loop.
The return path is the half that breaks quietly. A GRE tunnel with a wrong MTU, a return route that is itself caught by the diversion announcement, or asymmetric routing that confuses a stateful device: each turns a working divert into a black hole for legitimate users. A test that confirms diversion but never validates the return path has tested half the system.
RTBH and BGP Flowspec
Two coarser upstream tools sit alongside scrubbing, and both are double-edged.
Remote-triggered black hole (RTBH) asks your upstream to drop all traffic to a specific address by routing it to null. It stops the flood instantly, at the cost of completing the attacker's goal for that host: the target becomes unreachable by everyone, attacker and user alike. RTBH is a tourniquet. It is correct when one host is being targeted and amputating it protects everything else behind the same prefix, and catastrophic when the blackholed address is load-bearing.
BGP Flowspec is the granular alternative: it distributes match-and-drop rules (by port, protocol, packet length, source) to upstream routers, so a UDP reflection flood can be dropped by its signature without nulling the whole destination. Flowspec is more surgical and less widely supported across carriers, and its rules take time to propagate. A test should confirm both that your carrier honors Flowspec and that the rule you would actually deploy under attack matches the traffic you expect.
The stateful perimeter
This is where on-premise estates fail first, and it is the control the cloud abstracts away entirely.
Firewalls, load balancers, VPN concentrators, and inline mitigation appliances all hold per-connection state. A SYN flood or a connection flood does not aim to fill your pipe; it aims to fill the connection table of the first stateful device in the path. When that table is exhausted, the device stops accepting new connections, and legitimate users are refused by a box that is nowhere near its bandwidth rating.
The relevant ceiling is the state-table size and the new-connection rate the device can sustain, not its advertised Gbps. Conntrack exhaustion is the on-premise analog of the cloud's autoscaler window: an invisible limit that only surfaces under a shaped attack. Whether SYN cookies are enabled, whether the device sheds load gracefully or falls over, and which device in a chain of stateful boxes hits the wall first, are all empirical questions a test answers and a datasheet does not.
The mitigation appliance
A dedicated on-premise mitigation appliance drops attack traffic at the boundary using signatures, behavioral baselines, and rate controls. It is genuinely useful for what fits inside your pipe.
Its hard limit is that it sits behind your transit. It cannot mitigate an attack larger than the link feeding it, because that attack saturates the link before the appliance ever sees a clean copy. The appliance handles sub-saturation floods and the L7 work that upstream scrubbing handles coarsely; the volumetric ceiling still belongs to transit and scrubbing. A test characterizes the appliance against the load it can actually reach, and confirms its failure mode: does it fail open (passing traffic, including the attack) or closed (dropping everything) when overwhelmed.
What on-premise DDoS testing actually surfaces
A useful test is organized around the gaps that recur across on-premise and hybrid estates. None of these are exotic. They are the predictable result of owning the whole chain yourself.
The diversion window
This is the on-premise-distinctive finding, and the one most worth stating plainly: with on-demand scrubbing, enabled is not the same as engaged. There is a measurable window between attack onset and clean traffic, and the origin absorbs the attack for the entire window.
The window is the sum of several intervals. Detection has to recognize the attack and cross a threshold. The diversion has to be triggered, manually or automatically. The BGP announcement has to propagate and the internet's paths have to converge on the new route. Only then does traffic flow through the scrubber.
Each interval is independently measurable, and each is independently fixable. Automatic triggering removes a human from the detection-to-divert step. Faster detection thresholds shorten the first interval at the cost of false positives. Pre-staged announcements reduce convergence surprises. The test exists to turn the window from an assumption into a number.
The chart below puts a number on it. It is a small simulation of a volumetric flood against a data center on on-demand scrubbing: detection fires within minutes, but traffic keeps reaching the origin until the diversion announcement converges and scrubbing actually engages.
For an always-on posture, this window collapses to near zero, which is precisely the trade always-on buys. The test makes the cost of on-demand explicit, so the choice between the two is made against measured exposure rather than a billing line.
Stateful device exhaustion
The most common hard failure in an on-premise test is not a saturated pipe. It is a perimeter device that runs out of connection state at a traffic level well below its bandwidth rating.
The test drives connection-oriented floods (SYN floods, full-connection floods, slow attacks that hold connections open) at increasing rates and watches which device degrades first. The answer is frequently a firewall or load balancer that nobody suspected, refusing legitimate connections while its throughput graph looks idle.
The fix is usually a combination: SYN cookies to avoid half-open state, connection rate limits, and moving the stateful function behind upstream filtering that strips the flood before it reaches the table. None of that is knowable without driving the device to its actual ceiling.
The clean-pipe return path
A diversion that scrubs traffic but cannot return it is an outage you caused yourself.
The test validates the return path under load, not just at configuration time. It confirms the GRE tunnel or cross-connect carries production traffic volume, that its MTU does not fragment or drop large responses, and that return routing is not itself captured by the diversion announcement and looped. Asymmetric paths through stateful devices are a particular hazard: a stateful firewall that sees only one direction of a scrubbed flow may drop it as invalid.
Self-inflicted blackhole
RTBH is a tool that can complete the attack for the adversary if it is used carelessly.
A test should rehearse the blackhole decision, not just the mechanism. It confirms that the address being nulled is actually the target and is genuinely amputatable, that load-bearing services do not share the blackholed address, and that the team knows the difference between an RTBH that protects the estate and one that finishes the job the attacker started. The mechanism is trivial. The judgment is the part that fails under pressure.
Origin reachability when scrubbing is idle
On-demand scrubbing only protects traffic while it is diverted. Between diversions, the prefix routes directly to the data center, which means a flood that stays under the detection threshold never triggers a divert and reaches the origin unimpeded.
This is the on-premise shape of origin IP exposure. It is subtler than the cloud version, because the address is supposed to be reachable; the question is what an adversary can do to it before detection engages. A low-and-slow HTTP flood sitting just below the volumetric trigger, or an attack on a service hosted outside the protected prefix entirely, both reach the origin with no diversion ever firing.
The test confirms what is reachable, and at what rate, when scrubbing is idle. The same leak vectors that expose cloud origins apply here, explored in depth in how attackers bypass CDN DDoS protection.
Detection-to-mitigation timing
Vendors cite fast detection. The number that matters is the interval from attack onset to effective drop rate, measured end to end, for the specific vector against the specific path.
On-premise that interval is dominated by routing convergence, not by detection speed alone. An appliance that detects in seconds buys nothing if the BGP divert takes minutes to propagate. The useful measurement is the whole chain: onset to detection to trigger to convergence to clean traffic. Folding those numbers into a defensible posture score is the subject of DDoS resilience testing, and the underlying metric is time to mitigation.
Authorization: you own the gear, not the transit
On-premise testing inverts the cloud authorization problem. There is no platform acceptable-use policy gating your simulated attack, because you own the hardware. But you do not own the path to it, and that is where the coordination burden moves.
A high-volume test generates real traffic across your carrier's network and, if you trigger it, through your scrubbing provider's infrastructure. Both have to be in the loop. An unannounced volumetric test can trip a carrier's own automated mitigation, which may blackhole your prefix or rate-limit your links in ways that affect more than the test. A diversion triggered against a scrubbing provider who is not expecting it consumes their capacity and can read as a real event on their side.
The durable instruction is procedural, because the specifics differ by carrier and provider. Before any on-premise DDoS test: secure written authorization from the legal owner of the target infrastructure; notify and coordinate with every upstream carrier whose links the test will traverse; coordinate with the scrubbing provider if the test will trigger a real diversion; and agree an abort path with all of them in advance.
The general discipline of keeping a test from disrupting production sits underneath all of it. On-premise, the blast radius extends into networks you do not control, which raises the bar on coordination rather than lowering it.
Designing the test: environment, scope, and measurement
The discipline that keeps an on-premise DDoS test informative and non-destructive is the same that governs any production-adjacent test. The on-premise contour is here.
Environment selection
The strongest first target is a lab or pre-production segment that mirrors the production path: the same firewall model and ruleset, the same appliance, the same stateful devices in the same order, ideally behind a separate transit tail you can saturate without touching production links.
A faithful mirror exercises the real device behavior (the connection-table ceilings, the failure modes) without risking customer traffic. Where a finding can only be confirmed in production (the real BGP convergence time across your actual carriers, say), a tightly scoped window with explicit abort criteria and the carriers pre-notified scopes the risk.
Scope as a bounding document
The scope names the exact targets in play (the prefixes, the specific devices, the appliance, the scrubbing relationship), the vectors and maximum offered rates, the windows aligned to change-control, the monitoring signals that form the kill switch, and the escalation path that includes the carrier and scrubbing-provider contacts.
On-premise specifically, it should record the scrubbing posture (always-on or on-demand), whether the divert will be triggered for real or simulated short of the announcement, and the saturation ceiling of every link the test will load, because the test will deliberately probe how the chain behaves as that ceiling approaches.
Measurement per control
Each control gets its own measured outcome. Transit: the offered rate at which links saturate and legitimate traffic starts dropping. Scrubbing: detection-to-divert interval, convergence time, and clean-pipe return integrity under load. RTBH and Flowspec: propagation time and that the rule matched what it was meant to. The stateful perimeter: which device exhausts state first and at what new-connection rate. The appliance: throughput under load and its open-or-closed failure mode. The application: what a real user experienced through all of it.
The deliverable is not "the site stayed up." It is a per-control characterization: where the ceiling sits, which layer engaged, in what sequence, how long the window lasted, and what a real user experienced while it did.
Mapping attack classes to on-premise controls
A thorough test exercises each layer against the control meant to defend it. A stack tuned against one class can fail against another at a fraction of the volume.
- L3/L4 volumetric and protocol floods (UDP reflection, ACK flood, carpet-bombing) belong to upstream capacity and scrubbing. The volumetric case tests the saturation ceiling and the divert. Carpet-bombing, which spreads low volume across an entire prefix, tests whether aggregate detection works where a per-host trigger does not, since no single address may cross the threshold.
- State-table floods (SYN flood, connection flood, slow attacks) target the stateful perimeter, not the pipe. They exercise connection-table ceilings, SYN cookie behavior, and which device in the chain fails first. This is the class most likely to produce an outage at a traffic level that looks trivial on a bandwidth graph.
- L7 application floods (HTTP floods, slow attacks, application-logic abuse) are handled coarsely by scrubbing and finely by the appliance and application. Logic abuse (credential stuffing under the rate limit, expensive search, cart abuse) is the hardest, because the requests are valid; only application-aware rules tuned to your traffic catch them.
- Non-HTTP protocol attacks against a service on a raw public IP have no application-layer control in front of them. They test scrubbing and upstream filtering at L3/L4 in isolation, a different path from the HTTP traffic and easy to leave unexamined.
Procurement note: subscription versus project engagement
One consideration sits at the procurement layer, not the technical one. DDoS testing is sold both as an ongoing subscription and as a discrete project engagement.
The models suit different cadences. On-premise estates change at the pace of network and hardware projects: a new scrubbing contract, a firewall refresh, a carrier change, a data-center migration. Change-triggered testing maps naturally onto project engagements, because the meaningful changes are infrequent and discrete. Estates with constant network churn may prefer a standing capability.
Neither is universally correct. The annual-subscription commitments some vendors require can price out organizations whose real need is a handful of well-scoped tests around specific changes. Match the engagement model to the cadence the estate actually warrants, rather than the model a vendor leads with.
FAQ
What is on-premise DDoS testing?
Controlled, authorized generation of attack-shaped traffic against infrastructure you host yourself, to verify how your transit, scrubbing diversion, stateful perimeter, and application behave under adversarial pressure. Unlike cloud testing, there is no managed edge absorbing volume first, so the test characterizes the entire defensive chain, including the upstream diversion path you assemble yourself.
How is on-premise DDoS testing different from cloud DDoS testing?
The cloud platforms provide a global anycast edge that absorbs most volumetric traffic before your configuration is consulted. On-premise has no such edge. You own the transit, the scrubbing relationship, the BGP signaling, and the stateful devices, so the test measures things the cloud hides: the transit saturation ceiling, the on-demand diversion window, and which perimeter device exhausts connection state first.
What is the on-demand scrubbing diversion window?
It is the interval between attack onset and the moment clean traffic actually flows, on an on-demand scrubbing posture. It is the sum of detection time, divert trigger, and BGP convergence. During the window the origin absorbs the attack directly. Measuring and shrinking that window is the central goal of an on-premise test; an always-on posture collapses it to near zero at a steady-state cost.
Does on-premise DDoS testing require carrier coordination?
Usually, yes. A high-volume test traverses your upstream carriers' networks and may trigger their automated mitigation, and a real diversion consumes your scrubbing provider's capacity. Both should be notified and coordinated in advance, with an agreed abort path, alongside written authorization from the owner of the target infrastructure.
What fails first in an on-premise DDoS test?
More often than not, a stateful device runs out of connection-table state long before any link saturates. A SYN or connection flood exhausts a firewall or load balancer at a traffic rate that looks idle on a bandwidth graph, refusing legitimate users. Identifying which device hits that ceiling first is one of the most valuable outputs of the test.
Where on-premise resilience is actually decided
The durable knowledge from a test separates cleanly from the perishable. Five years from now, your transit will still have a finite ceiling, stateful devices will still exhaust their tables before their bandwidth, BGP will still take time to converge, and on-demand scrubbing will still open a window the cloud does not have. Those are stable.
What changes constantly, and so must be re-verified, is everything layered on top:
- the diversion automation, which silently regresses to manual the first time someone disables a flapping detector and forgets to re-enable it
- the clean-pipe return, which a routine routing change can capture or break without anyone noticing until a divert fails
- the stateful ceiling, which a firewall refresh resets to an unknown new value
- the scrubbing posture, where an always-on contract quietly lapses to on-demand at renewal and reopens the window
- the protected prefix, which a new service stood up outside it reaches around entirely
A cloud platform absorbs the volumetric blow whether or not your configuration is correct, and punishes only your application-layer mistakes. On-premise grants no such forgiveness. The volumetric ceiling is yours, the diversion timing is yours, and the connection table that fills first is yours.
That is why on-premise DDoS testing is a recurring discipline rather than a one-time gate. The physics of transit and state do not change. The configuration sitting on top of them drifts the moment the network stops being static, and on-premise there is no edge waiting to catch what drifts.