Skip to content
MikroTik RouterOS Docs

MikroTik RouterOS Ping Tool: Connectivity Testing and Diagnostics

MikroTik RouterOS Ping Tool: Connectivity Testing and Diagnostics

Section titled “MikroTik RouterOS Ping Tool: Connectivity Testing and Diagnostics”

RouterOS Version: 6.x / 7.x Difficulty: Beginner Estimated Time: 15 minutes

Overview

Section titled “Overview”

The ping tool is your first line of defense when diagnosing network issues. It sends ICMP Echo Request packets to a target and measures the response time, helping you verify connectivity, measure latency, and identify network problems.

RouterOS ping supports IPv4, IPv6, and even MAC address pinging on local network segments. Beyond basic connectivity testing, it’s commonly used for MTU path discovery, failover scripting, and integration with monitoring tools like Netwatch.

Basic Usage

Section titled “Basic Usage”

Simple Connectivity Test

Section titled “Simple Connectivity Test”
/ping 8.8.8.8 count=5

Example Output:

  SEQ HOST                                     SIZE TTL TIME  STATUS
    0 8.8.8.8                                    56  55 14ms
    1 8.8.8.8                                    56  55 13ms
    2 8.8.8.8                                    56  55 14ms
    3 8.8.8.8                                    56  55 13ms
    4 8.8.8.8                                    56  55 14ms
    sent=5 received=5 packet-loss=0% min-rtt=13ms avg-rtt=13ms max-rtt=14ms

Key output fields:

  • SEQ - Packet sequence number
  • TTL - Time To Live remaining after reaching destination
  • TIME - Round-trip time in milliseconds
  • packet-loss - Percentage of packets that didn’t receive replies

Ping by Hostname

Section titled “Ping by Hostname”
/ping www.google.com count=5

RouterOS resolves the hostname using its configured DNS servers.

Note: When using CLI, the router’s DNS is used. When using Winbox Tools > Ping, your computer’s DNS is used. This can cause different results.

IPv6 Ping

Section titled “IPv6 Ping”
/ping 2001:4860:4860::8888 count=5

Continuous Ping

Section titled “Continuous Ping”

Run indefinitely until you press Ctrl+C:

/ping 8.8.8.8

Common Parameters

Section titled “Common Parameters”
ParameterDefaultDescription
countunlimitedNumber of pings to send
interval1sTime between pings
size56ICMP payload size in bytes
ttl64Time To Live value
src-addressautoSource IP address to use
interfaceautoForce specific outgoing interface
routing-tablemainVRF/routing table to use
do-not-fragmentnoSet DF flag (for MTU testing)
arp-pingnoUse ARP instead of ICMP
dscp0QoS marking for the ping packets

MTU Path Discovery

Section titled “MTU Path Discovery”

Use ping with the do-not-fragment flag to find the maximum packet size that can traverse a path without fragmentation.

Standard Ethernet (1500 MTU)

Section titled “Standard Ethernet (1500 MTU)”
# Maximum ping size for 1500 MTU = 1500 - 28 = 1472
/ping 8.8.8.8 size=1472 do-not-fragment count=1

If successful, the path supports standard 1500 byte MTU.

Finding Actual Path MTU

Section titled “Finding Actual Path MTU”

If the above fails with “packet too large”, decrease the size:

/ping 8.8.8.8 size=1400 do-not-fragment count=1
/ping 8.8.8.8 size=1300 do-not-fragment count=1
# Continue until ping succeeds

Common MTU Scenarios

Section titled “Common MTU Scenarios”
Connection TypeMTUMax Ping Size
Standard Ethernet15001472
PPPoE14921464
IPsec Tunnel~1400~1372
GRE Tunnel14761448

Why subtract 28? ICMP packets have 20 bytes of IP header + 8 bytes of ICMP header = 28 bytes overhead.

Source Address and Interface Control

Section titled “Source Address and Interface Control”

Specify Source Address

Section titled “Specify Source Address”
/ping 10.0.0.1 src-address=192.168.1.1 count=5

Caveat: The src-address parameter may be overridden by routing decisions. For reliable source selection, use the routing-table parameter with a dedicated routing table.

Force Specific Interface

Section titled “Force Specific Interface”
/ping 8.8.8.8 interface=ether1 count=5
Section titled “Using VRF/Routing Tables (Recommended for Multi-WAN)”
# Ping through specific WAN connection
/ping 8.8.8.8 routing-table=wan1 count=5

This is the most reliable method for testing specific paths in multi-WAN setups.

Layer 2 Diagnostics

Section titled “Layer 2 Diagnostics”

MAC Ping

Section titled “MAC Ping”

Ping a device by its MAC address on the local network segment:

# First, enable MAC ping server on target devices
/tool mac-server ping set enabled=yes


# Ping by MAC (specify interface to avoid flooding all ports)
/ping 00:11:22:33:44:55%ether1 count=3

Without the %interface suffix, the router sends the ping out all interfaces, which can cause unnecessary traffic.

ARP Ping

Section titled “ARP Ping”

Test layer 2 reachability without ICMP:

/ping 192.168.1.1 arp-ping count=3

ARP ping only works for hosts on the same broadcast domain - it cannot cross routers.

IPv6 Multicast Discovery

Section titled “IPv6 Multicast Discovery”

Discover all IPv6-enabled devices on the local link:

/ping ff02::1 count=3

This pings the “all nodes” multicast group. You may receive multiple replies (one from each device), which can show negative packet loss in statistics - this is normal.

Scripting Integration

Section titled “Scripting Integration”

Basic Connectivity Check

Section titled “Basic Connectivity Check”

The ping command returns the number of successful replies:

:local result [/ping 8.8.8.8 count=3]
:if ($result = 0) do={
    :log warning "Host unreachable"
} else={
    :log info "Host reachable ($result/3 replies)"
}

Failover Script Example

Section titled “Failover Script Example”
# Global variable to track state
:global primaryUp true


# Check primary WAN
:local result [/ping 8.8.8.8 count=3 interval=500ms routing-table=wan1]


:if ($result = 0) do={
    # Primary is down
    :if ($primaryUp) do={
        :log warning "Primary WAN DOWN - switching to backup"
        /ip route set [find comment="primary-default"] distance=10
        /ip route set [find comment="backup-default"] distance=1
        :set primaryUp false
    }
} else={
    # Primary is up
    :if (!$primaryUp) do={
        :log info "Primary WAN UP - restoring"
        /ip route set [find comment="primary-default"] distance=1
        /ip route set [find comment="backup-default"] distance=10
        :set primaryUp true
    }
}

Key point: Track state to avoid repeated alerts. Only take action when state changes.

Scheduled Ping Check

Section titled “Scheduled Ping Check”

Create a scheduler to run the check periodically:

/system scheduler add name=wan-check interval=1m on-event="/system script run wan-failover"

Verification Examples

Section titled “Verification Examples”

Check 1: Basic Internet Connectivity

Section titled “Check 1: Basic Internet Connectivity”
/ping 8.8.8.8 count=5

Expected: 0% packet loss, reasonable RTT (depends on your connection).

Check 2: DNS Resolution

Section titled “Check 2: DNS Resolution”
/ping www.google.com count=3

Expected: Hostname resolves and ping succeeds.

Check 3: Path MTU

Section titled “Check 3: Path MTU”
/ping 8.8.8.8 size=1472 do-not-fragment count=1

Expected: Success if path supports 1500 MTU.

Section titled “Check 4: Specific WAN Link”
/ping 8.8.8.8 routing-table=wan1 count=3
/ping 8.8.8.8 routing-table=wan2 count=3

Expected: Both succeed if both WANs are operational.

Check 5: Local Device via MAC

Section titled “Check 5: Local Device via MAC”
/ping 4C:5E:0C:12:34:56%ether2 count=3

Expected: Replies if device is on that interface and MAC ping server is enabled.

Troubleshooting

Section titled “Troubleshooting”

Problem: “Host unreachable”

Section titled “Problem: “Host unreachable””

Causes:

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

Solution:

  1. Check routing: /ip route print where dst-address=0.0.0.0/0
  2. Try traceroute to see where it fails: /tool traceroute 8.8.8.8
  3. Check firewall rules on both ends

Problem: “TTL expired in transit”

Section titled “Problem: “TTL expired in transit””

Cause: TTL too low for the number of hops to destination, or routing loop.

Solution:

  1. Increase TTL: /ping 8.8.8.8 ttl=128
  2. If still failing, check for routing loops with traceroute

Problem: “Packet too large”

Section titled “Problem: “Packet too large””

Cause: Using do-not-fragment with size larger than path MTU.

Solution: Decrease size until ping succeeds to find actual path MTU.

Problem: “src-address ignored”

Section titled “Problem: “src-address ignored””

Cause: Routing decision overrides the specified source.

Solution: Use routing-table parameter with a dedicated routing table that has the correct gateway for your intended source.

Problem: “MAC ping not working”

Section titled “Problem: “MAC ping not working””

Causes:

  • MAC ping server disabled on target
  • Target not on same broadcast domain
  • Wrong interface specified

Solution:

  1. Enable MAC ping server: /tool mac-server ping set enabled=yes
  2. Verify layer 2 connectivity
  3. Specify correct interface: /ping MAC%interface

Problem: “ARP ping fails to remote network”

Section titled “Problem: “ARP ping fails to remote network””

Cause: ARP is layer 2 only - cannot cross routers.

Solution: Use regular ICMP ping for hosts on different subnets.

Common Pitfalls

Section titled “Common Pitfalls”

1. MAC Ping Without Interface Specification

Section titled “1. MAC Ping Without Interface Specification”

Wrong:

/ping 00:11:22:33:44:55  # Floods all interfaces

Right:

/ping 00:11:22:33:44:55%ether1  # Targets specific interface

2. Confusing Ping Size with MTU

Section titled “2. Confusing Ping Size with MTU”

Wrong thinking: “I can ping with size=1500, so my MTU is 1500”

Right: Ping size + 28 bytes overhead = actual packet size. For 1500 MTU, max ping size is 1472.

3. Script Flooding Logs/Alerts

Section titled “3. Script Flooding Logs/Alerts”

Wrong:

:if ([/ping 8.8.8.8 count=1] = 0) do={
    :log warning "Link down!"  # Logs every minute when down
}

Right: Track state and only log on changes (see failover script example above).

4. Relying on src-address for Multi-WAN

Section titled “4. Relying on src-address for Multi-WAN”

Wrong:

/ping 8.8.8.8 src-address=10.0.0.2  # May be ignored

Right:

/ping 8.8.8.8 routing-table=wan1  # Reliable path selection

5. Expecting ARP Ping to Work Across Routers

Section titled “5. Expecting ARP Ping to Work Across Routers”

Wrong:

/ping 10.20.30.40 arp-ping  # Fails - different subnet

Right: Use ARP ping only for hosts on the same broadcast domain.

Section titled “Related Topics”

Troubleshooting Tools

Section titled “Troubleshooting Tools”

Monitoring

Section titled “Monitoring”
  • Netwatch - automated host monitoring with actions
  • Flood Ping - high-rate ping for stress testing
Section titled “Related Concepts”

References

Section titled “References”