MikroTik RouterOS Flood Ping: Network Stress Testing and Latency Measurement

MikroTik RouterOS Flood Ping: Network Stress Testing and Latency Measurement

RouterOS Version: 6.x / 7.x Difficulty: Intermediate Estimated Time: 10 minutes

Overview

The Flood Ping tool (/tool flood-ping) sends ICMP Echo Request packets as fast as possible without waiting for the normal interval between packets. Unlike regular ping, flood-ping sends the next request immediately upon receiving a reply, allowing rapid network stress testing and precise latency measurement.

The primary advantage of flood-ping over regular ping is its do={} script block, which provides access to round-trip time statistics (avg-rtt, min-rtt, max-rtt) during execution. This makes flood-ping essential for automated monitoring scripts that need to make decisions based on latency rather than simple reachability.

Basic Usage

Simple Flood Ping Test

/tool flood-ping 8.8.8.8 count=100

This sends 100 ICMP packets as quickly as possible and displays statistics.

Flood Ping with Script Block

:local avgRtt
/tool flood-ping 8.8.8.8 count=10 do={
    :if ($sent = 10) do={
        :set avgRtt $"avg-rtt"
    }
}
:put "Average RTT: $avgRtt ms"

Key point: The do={} block executes at the start, end, and at every interval, not just when complete. Use $sent to detect completion.

Command Parameters

Parameter	Type	Default	Description
address	IP	(required)	Target IP address
count	integer	unlimited	Number of packets to send
size	integer	56	ICMP payload size in bytes
interval	time	10ms	Minimum delay between packets
timeout	time	1s	Time to wait for each reply
do	script	-	Script block executed during test

Variables Available in do={} Block

Variable	Type	Description
$sent	integer	Number of packets sent so far
$received	integer	Number of replies received
$"avg-rtt"	integer	Average round-trip time (ms)
$"min-rtt"	integer	Minimum round-trip time (ms)
$"max-rtt"	integer	Maximum round-trip time (ms)

Note: Variables with hyphens require quoting: $"avg-rtt", not $avg-rtt.

Common Scenarios

Scenario: Capture Average Latency

:local avgRtt 0
/tool flood-ping 8.8.8.8 count=10 do={
    :if ($sent = 10) do={
        :set avgRtt $"avg-rtt"
    }
}
:log info "Average latency to 8.8.8.8: $avgRtt ms"

Scenario: Monitor Packet Loss

:local sent 0
:local received 0
:local packetLoss 0

/tool flood-ping 8.8.8.8 count=100 do={
    :if ($sent = 100) do={
        :set sent $sent
        :set received $received
    }
}

:if ($received > 0) do={
    :set packetLoss (($sent - $received) * 100 / $sent)
}
:log info "Packet loss: $packetLoss%"

Scenario: Latency-Based Alert

:local avgRtt 0
:local threshold 100

/tool flood-ping 8.8.8.8 count=10 do={
    :if ($sent = 10) do={
        :set avgRtt $"avg-rtt"
    }
}

:if ($avgRtt > $threshold) do={
    :log warning "High latency detected: $avgRtt ms (threshold: $threshold ms)"
}

Scenario: Compare WAN Link Latency

Test latency to a target via both WAN connections by running tests sequentially (flood-ping cannot specify routing-table directly):

:local wan1Rtt 0
:local wan2Rtt 0

# Test via WAN1 gateway
/tool flood-ping 203.0.113.1 count=10 do={
    :if ($sent = 10) do={ :set wan1Rtt $"avg-rtt" }
}

# Test via WAN2 gateway
/tool flood-ping 198.51.100.1 count=10 do={
    :if ($sent = 10) do={ :set wan2Rtt $"avg-rtt" }
}

:log info "WAN1 RTT: $wan1Rtt ms, WAN2 RTT: $wan2Rtt ms"

Scenario: Complete Monitoring Script with Email

:local host "8.8.8.8"
:local packetCount 10
:local avgRtt 0
:local minRtt 0
:local maxRtt 0
:local sent 0
:local received 0

/tool flood-ping $host count=$packetCount do={
    :if ($sent = $packetCount) do={
        :set avgRtt $"avg-rtt"
        :set minRtt $"min-rtt"
        :set maxRtt $"max-rtt"
        :set sent $sent
        :set received $received
    }
}

:local packetLoss 0
:if ($sent > 0) do={
    :set packetLoss (($sent - $received) * 100 / $sent)
}

:local report "Flood Ping Report\r\n"
:set report ($report . "Target: $host\r\n")
:set report ($report . "Sent: $sent, Received: $received, Loss: $packetLoss%\r\n")
:set report ($report . "RTT: min=$minRtt ms, avg=$avgRtt ms, max=$maxRtt ms")

:log info $report

Flood Ping vs Regular Ping

Feature	/ping	/tool flood-ping
RTT statistics in scripts	No	Yes ($"avg-rtt", etc.)
interface parameter	Yes	No
routing-table parameter	Yes	No
src-address parameter	Yes	No
do={} script block	No	Yes
Default interval	1s	10ms
Primary use	Connectivity testing	Latency measurement, stress testing

When to use flood-ping: Use flood-ping when you need to capture latency metrics (avg-rtt, min-rtt, max-rtt) in scripts for automated decision-making.

When to use regular ping: Use regular ping when you need interface selection, routing-table specification, or simple reachability testing.

Verification Examples

Check 1: Basic Flood Ping

/tool flood-ping 8.8.8.8 count=10

Expected: Statistics showing sent, received, packet loss, and RTT values.

Check 2: Capture RTT in Variable

:local rtt
/tool flood-ping 8.8.8.8 count=5 do={
    :if ($sent = 5) do={ :set rtt $"avg-rtt" }
}
:put $rtt

Expected: Numeric RTT value in milliseconds.

Check 3: Large Packet Test

/tool flood-ping 8.8.8.8 count=10 size=1472

Expected: Success if path supports 1500 MTU.

Troubleshooting

Problem: Script variables remain empty

Cause: The do={} block executes multiple times, including at start when values are zero.

Solution: Check $sent equals your target count before capturing values:

:if ($sent = 10) do={
    :set avgRtt $"avg-rtt"
}

Problem: “invalid value” error for RTT variables

Cause: Variables with hyphens must be quoted.

Wrong:

:set avgRtt $avg-rtt

Right:

:set avgRtt $"avg-rtt"

Problem: Cannot specify interface or routing-table

Cause: Flood-ping does not support interface or routing-table parameters.

Workaround: Ping specific gateway IPs directly or use the regular /ping command for path-specific tests (though you lose RTT variable access).

Problem: Host unreachable

Causes:

• No route to destination
• Firewall blocking ICMP
• Target host is down

Solution: First verify connectivity with regular ping, then check routing and firewall rules.

Problem: High CPU usage during test

Cause: Flood-ping is CPU-intensive, especially with high packet counts.

Solution: Use reasonable count values (10-100) for monitoring scripts. Reserve larger counts for dedicated stress testing during maintenance windows.

Common Pitfalls

1. Not Checking $sent Before Capturing Values

Wrong:

/tool flood-ping 8.8.8.8 count=10 do={
    :set avgRtt $"avg-rtt"  # Captures zero at start!
}

Right:

/tool flood-ping 8.8.8.8 count=10 do={
    :if ($sent = 10) do={
        :set avgRtt $"avg-rtt"  # Captures final value
    }
}

2. Expecting Interface Selection

Flood-ping cannot specify which interface to use. If you need interface-specific testing, use regular ping (without RTT variable access) or ping specific gateway addresses.

3. Using for Simple Reachability

For simple up/down monitoring, regular ping with Netwatch is more appropriate. Use flood-ping when you specifically need latency metrics.

4. Running Continuous Flood Pings

Unlike regular ping, flood-ping without a count parameter runs indefinitely at high speed, consuming significant CPU and generating substantial traffic.

Wrong:

/tool flood-ping 8.8.8.8  # Runs forever at maximum rate

Right:

/tool flood-ping 8.8.8.8 count=10  # Bounded test

5. Forgetting Variable Quoting

Variables with hyphens require quotes around the name.

Scheduled Monitoring Example

Create a scheduler to run latency checks periodically:

/system script add name=latency-check source={
    :local avgRtt 0
    :local threshold 100

    /tool flood-ping 8.8.8.8 count=10 do={
        :if ($sent = 10) do={
            :set avgRtt $"avg-rtt"
        }
    }

    :if ($avgRtt > $threshold) do={
        :log warning "High latency: $avgRtt ms"
    }
}

/system scheduler add name=latency-monitor interval=5m on-event="/system script run latency-check"

Related Tools

• Ping (/ping) - Standard connectivity testing with interface/routing-table support
• Traceroute (/tool traceroute) - Path discovery to destination
• Netwatch (/tool netwatch) - Automated host monitoring with up/down actions
• Bandwidth Test (/tool bandwidth-test) - Throughput measurement between MikroTik devices
• Traffic Monitor (/tool traffic-monitor) - Real-time interface statistics

References

• MikroTik Ping Documentation
• RFC 792 - ICMP - Internet Control Message Protocol

Related Topics

Diagnostic Tools

• Ping Tool - standard connectivity testing with interface selection
• Traceroute - path discovery to destination
• Bandwidth Test - throughput measurement

Monitoring

• Netwatch - automated host monitoring with up/down actions
• Traffic Monitor - real-time interface statistics

Automation

• Scheduler - run latency checks periodically
• Email Tool - send latency alerts