ddos-simulation.com
Build a test plan

Layer 3 · Network · icmp_flood

ICMP (ping) flood test

The icmp_flood simulation sends a fixed echo request per operation to measure how your infrastructure handles network-layer noise. It is a bounded rehearsal of a classic ping flood against a host you own.

Layer L3 Protocol ICMP Command icmp_flood Access After verification

What an ICMP flood does

An ICMP (ping) flood sends a high rate of echo-request packets to consume bandwidth and force the target and intervening devices to spend cycles generating replies. On its own it is rarely fatal to a well-provisioned host, but it is a useful probe of how much network-layer noise your edge absorbs before it starts to matter.

How ddos-simulation.com simulates it safely

ddos-simulation.com sends a fixed echo request per operation to a single verified domain pinned to a public address, with the rate held inside the domain's limits. No packets are forged and no other host is touched.

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

  • ICMP rate limiting and filtering at the edge
  • Bandwidth headroom to the origin
  • Router and firewall handling of echo traffic
  • Whether ICMP is (correctly) deprioritized or dropped
  • Baseline network-layer noise tolerance

When to run an ICMP flood test

Run an ICMP flood test when you want a baseline for how the network layer and its rate limits react to raw packet noise.

  • You want to confirm ICMP rate limiting or filtering at the edge behaves as configured.
  • You're measuring how much network-layer noise the path absorbs before it affects real traffic.
  • You need a simple, low-risk first probe before scheduling heavier network-layer tests.

How to run a icmp flood test

  1. Verify your domain. Prove ownership over HTTPS — it is self-service and takes minutes.
  2. Add the icmp_flood command to a timeline in the portal and set the target path or 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 latency, status codes, and worker timeline to find where your service starts to bend.

Configure a icmp flood test in the portal →

Reading the results

Resilient: ICMP is rate-limited or dropped at the edge, real-traffic latency is unchanged, and no device spends meaningful CPU on echo handling.

Under strain: Echo traffic reaches and loads the origin, latency for real traffic rises, or a device processes every packet instead of shedding it.

Availability & limits

ICMP floods are available after your domain is verified and are priced per engagement — request a quote.

Frequently asked questions

Is an ICMP flood usually enough to take a site down?

Rarely on its own against well-provisioned infrastructure. It is most useful as a probe of edge filtering and bandwidth headroom, and as a baseline for network-layer noise tolerance.

Which hosts are affected?

Only your single verified, publicly-resolved domain. Private and loopback addresses are blocked and nothing is spoofed.

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

Build a test plan
← All DDoS simulations