ddos-simulation.com
Build a test plan

Layer 3 · Network · ip_fragment_flood

IP fragment flood test

The ip_fragment_flood simulation emits raw IPv4 fragments of datagrams that never complete, at a guaranteed rate, against a domain you own — real packets from the worker's own address, nothing spoofed. Each fragment pins a reassembly context open until it times out, pressuring the target's packet-reassembly buffers — a path whole-datagram floods never reach — while staying attributable and in-bounds.

Layer L3 Protocol IPv4 Command ip_fragment_flood Access Reviewed engagement

What an IP fragment flood does

An IP fragmentation flood sends a high rate of IP fragments that are the opening piece of a larger datagram whose remaining fragments never arrive. The target must hold each one in a reassembly buffer, keyed by source, destination, protocol, and fragment identifier, waiting for the rest — until a reassembly timeout expires. With a fresh identifier on every packet, each opens a distinct reassembly context rather than adding to one, so memory and bookkeeping, not bandwidth, are what climb. Any firewall or middlebox that reassembles before it can filter pays the same cost.

How ddos-simulation.com simulates it safely

ddos-simulation.com emits raw IPv4 fragments at a guaranteed rate from the worker's real address to a single verified domain pinned to a public address — the fragments are crafted to never complete, but the source is never forged. The rate stays inside the limits set for that domain, health checks watch the target throughout, and the run aborts itself the moment a threshold you set is crossed.

Authorized targets only

Every run is bound to one verified domain you have proven you own. Ownership is checked over HTTPS before anything is scheduled, and running traffic against systems you do not own or are not clearly authorized to test may be unlawful. See the Acceptable Use Policy.

What the test exercises

  • IP reassembly-buffer memory ceilings and per-context bookkeeping
  • Reassembly-timeout machinery under a flood of incomplete datagrams
  • Firewall and middlebox reassembly capacity
  • Resilience independent of the transport and application layers
  • Time-to-degrade and recovery once the flood stops

When to run an IP fragment flood test

Run an IP fragment flood test when you need to prove the network-layer reassembly path, not the transport or application stack.

  • A firewall or middlebox in front reassembles fragments before filtering and you need evidence it holds under incomplete-datagram pressure.
  • You want to confirm reassembly-buffer limits and timeouts are tuned so a fragment flood cannot exhaust memory.
  • You are covering a genuinely distinct vector that whole-datagram UDP or TCP floods do not reach.

How to run an IP fragment flood test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the ip_fragment_flood command to a timeline in the portal and set the target port, rate, and duration.
  3. Set health thresholds. Choose the error-rate, latency, or status-code limits at which the test should abort itself.
  4. Run and watch. Bounded workers are provisioned minutes before start and torn down the moment the last task ends, while metrics stream live.
  5. Read the results. Review the recorded reachability, latency, and worker timeline to find where your service starts to bend.

Configure an IP fragment flood test in the portal →

Reading the results

Resilient: Incomplete fragments are capped and timed out cleanly, reassembly memory stays bounded, and legitimate traffic is untouched.

Under strain: Reassembly buffers fill, memory or CPU climbs holding incomplete datagrams, or legitimate fragmented traffic starts to drop — signs the reassembly path, not bandwidth, is the bottleneck.

Availability & limits

The IP fragment flood is a network-layer technique reviewed and approved before it runs (a manual review, beyond verifying you own the domain) and is priced per engagement — request a quote.

Frequently asked questions

Does this spoof source addresses?

No. Every fragment is emitted from the worker's own public address. The fragments are crafted to never complete reassembly, but the source is never forged.

What does an IP fragment flood actually stress?

It stresses the packet-reassembly path. Each fragment is the opening piece of a larger datagram whose remaining fragments never arrive, so the target must allocate a reassembly context and hold it until a timeout expires. With a fresh identifier on every packet, each opens a distinct context, driving reassembly-buffer memory and bookkeeping — a path that whole-datagram floods never touch.

Rehearse an IP fragment flood against infrastructure you own — bounded, monitored, and stopped the instant you have your answer.

Build a test plan
← All DDoS simulations