Introduction
When managing or troubleshooting a network, understanding the path your traffic takes is vital for identifying bottlenecks, latency spikes, and connection drops. For network administrators using MikroTik RouterBOARD hardware or RouterOS, the mikrotik traceroute tool is an indispensable diagnostic utility. Whether you are investigating packet drops, verifying multi-WAN routing behaviors, or identifying which transit provider is failing, knowing how to execute and analyze a traceroute in MikroTik is a core engineering skill.
In this comprehensive guide, we will cover how to run a traceroute via both WinBox and the terminal CLI, dive deep into the mechanics of packet routing, detail advanced RouterOS v7 multi-WAN features, and fix common troubleshooting bugs like 100% packet loss.
The Anatomy of a Traceroute: How It Works under the Hood
To effectively use and troubleshoot traceroute, it is important to understand the underlying networking mechanics. Traceroute functions by exploiting a fundamental field in the IP header: the Time to Live (TTL).
- The TTL Field: The TTL field is an 8-bit field designed to prevent packets from looping endlessly in a network. Every time a router (a "hop") forwards an IP packet, it decrements the TTL value by 1.
- The Discard & Notify Phase: If a router receives a packet with a TTL of 1, it decrements it to 0. Instead of forwarding the packet, the router discards it and sends an ICMP Type 11, Code 0 (Time Exceeded) packet back to the original sender. This packet contains the IP address of the discarding router, allowing the sender to identify that hop.
- The Incremental Probe Process: The traceroute tool begins by sending a packet with a TTL of 1. The first router decrements it, drops it, and replies. This reveals the first hop. Next, the tool sends a packet with a TTL of 2, which reaches the second router before expiring, and so on, until the packet successfully reaches the final destination.
MikroTik Continuous Tracing vs. Traditional Traceroute
Standard traceroute implementations (such as the tracert command in Windows) send three packets to each hop, output the results, and terminate.
In contrast, the trace route mikrotik tool runs continuously by default. It operates similarly to "My Traceroute" (MTR), constantly sending probes and dynamically updating statistics like average latency, worst latency, and jitter. This continuous behavior is incredibly powerful for identifying intermittent packet drops or latency spikes over time, though it requires you to manually stop the tool (or configure a packet limit) when using the command line.
Running Traceroute in MikroTik WinBox (GUI)
For administrators who prefer a graphical user interface, performing a traceroute in mikrotik via WinBox is straightforward and highly visual.
Step-by-Step WinBox Guide
- Launch WinBox and log in to your MikroTik router.
- In the left-hand navigation sidebar, click on Tools.
- Select Traceroute from the dropdown menu to open the traceroute utility window.
- In the Traceroute window, configure the following parameters:
- Traceroute To: Enter the destination IP address or fully qualified domain name (FQDN) you want to trace (e.g.,
8.8.8.8orgoogle.com). - Packet Size: The default size is 56 bytes. You can increase this to test path Maximum Transmission Unit (MTU) limits or check for fragmentation issues.
- Timeout: The length of time the router will wait for a response before marking the hop as timed out (default is 1000ms).
- Protocol: Select either
icmporudp. ICMP uses echo requests (like ping), whereas UDP sends packets to random high-range UDP ports. ICMP is generally more reliable as many firewalls block arbitrary outbound UDP traffic. - Use DNS: Check this box if you want the router to perform reverse PTR DNS lookups to resolve each hop's IP address into a readable hostname. This is highly recommended for identifying specific transit ISPs along the path.
- Count: Leave empty for continuous testing, or enter a numeric value (e.g.,
10) to automatically stop the trace after sending that many probes.
- Traceroute To: Enter the destination IP address or fully qualified domain name (FQDN) you want to trace (e.g.,
- Click the Start button on the right side of the window.
Understanding the WinBox Output Columns
Once the trace begins, the window populates with several columns of real-time diagnostics:
- #: The hop count/index, indicating the sequence of routers along the path.
- Address: The IP address or resolved domain name of the router at that hop.
- Loss: The percentage of sent packets that failed to return a response.
- Sent: The total number of probes transmitted to that hop.
- Last: The round-trip time (latency) of the most recently received packet in milliseconds.
- Avg: The average round-trip time across all sent probes.
- Best: The lowest round-trip latency recorded.
- Worst: The highest round-trip latency recorded.
- Std-Dev (Standard Deviation): A critical metric representing latency consistency (jitter). A high standard deviation value indicates a highly unstable path, which degrades real-time services like VoIP, video calling, and online gaming.
- Status: Displays the status of the probe (e.g., "timeout" if no reply was received).
Master the MikroTik Traceroute Command in Terminal (CLI)
Running a traceroute mikrotik terminal session is often faster for experienced administrators, and it is a requirement when writing automated diagnostic scripts.
Basic Command Usage
To initiate a quick traceroute to a target IP from the console, open a New Terminal and run the following mikrotik traceroute command:
/tool traceroute 8.8.8.8
Because the console version is continuous, the trace will run indefinitely, updating the terminal screen in real-time. To stop the traceroute and return to the terminal prompt, press Ctrl + C.
Advanced CLI Parameters
To perform targeted diagnostic tests, you can append various optional parameters to the command. The syntax for the complete CLI command is:
/tool traceroute address=<destination> [packet-size=<bytes>] [timeout=<time>] [protocol=<icmp|udp>] [use-dns=<yes|no>] [count=<number>] [max-hops=<number>] [src-address=<IP>] [interface=<name>]
Here is a comprehensive breakdown of the essential parameters you can use in the mikrotik traceroute terminal:
| Parameter | Accepted Values | Default | Description |
|---|---|---|---|
address |
IP Address or FQDN | None | The target host you want to trace (e.g., 1.1.1.1 or google.com). |
packet-size |
Integer (28 to 65535) | 56 | Defines the size of the sent packet in bytes. Useful for finding packet fragmentation issues along the route. |
timeout |
Time (e.g., 1s, 500ms) |
1s |
The duration the router waits for a response from each hop before assuming packet loss. |
protocol |
icmp or udp |
icmp (depending on RouterOS config) |
The protocol used for probes. Use icmp to avoid intermediate firewalls blocking UDP traceroute packets. |
use-dns |
yes or no |
no |
Toggles reverse DNS hostname lookup for each discovered IP hop. |
count |
Integer | Infinite | Limits the number of trace rounds. Recommended if running traces inside scripts to avoid lockups. |
max-hops |
Integer (1 to 255) | 30 | The maximum number of hops (TTL) the trace will traverse before terminating. |
src-address |
Local IP Address | Dynamic | Forces the traceroute packets to originate from a specific IP bound to one of the router's interfaces. |
interface |
Interface Name | Dynamic | Forces the traceroute out of a specific physical interface, VLAN, or tunnel. |
Practical CLI Examples
Example 1: Run a traceroute limited to exactly 10 packets with DNS lookup enabled:
/tool traceroute address=8.8.8.8 count=10 use-dns=yes
Example 2: Force a traceroute to use ICMP, originating from a specific LAN IP (to test routing from the local network's perspective):
/tool traceroute address=1.1.1.1 protocol=icmp src-address=192.168.88.1 count=5
Example 3: Test for MTU issues on a WAN link by sending large 1500-byte packets:
/tool traceroute address=8.8.8.8 packet-size=1500 count=5
Advanced Multi-WAN and VRF Routing in RouterOS v7 (The Modern Syntax)
In older RouterOS v6 systems, policy-based routing (PBR) and Virtual Routing and Forwarding (VRF) diagnostics were managed by passing a routing mark as an argument to the traceroute command (e.g., routing-table=ISP1).
The RouterOS v7 Paradigm Shift
RouterOS v7 completely overhauled the routing engine. Decoupled routing tables and refined VRFs changed how diagnostics interact with the routing stack.
Starting with recent RouterOS v7 updates (specifically RouterOS v7.21 and later), MikroTik removed explicit VRF/routing-table selection dropdowns and parameters from the ping and traceroute utilities. Attempting to use old command-line arguments will return configuration errors.
The Unified At-and-Percent (@ & %) Syntax
To perform a traceroute in mikrotik through a specific VRF, routing table, or interface in modern RouterOS v7, you must format the destination address itself using a combined syntax:
$$\text{Target Address}%\text{[Interface]}@\text{[VRF/Routing Table]}$$
Here are the three structural options you can use:
Trace via a specific VRF or Routing Table (
@): Append@followed by the VRF/routing table name to the target IP./tool traceroute 8.8.8.8@Office-VRFTrace out of a specific Interface (
%): Append%followed by the interface name to the target IP./tool traceroute 8.8.8.8%ether1-WANCombine Interface and VRF (
%and@): Specify both parameters sequentially in the destination field./tool traceroute 8.8.8.8%ether1-WAN@Office-VRF
This unified syntax is extremely useful for verifying routing policies in dual-WAN setups. If you are running a load balancer like PCC (Per Connection Classifier), this method allows you to verify that a specific gateway path is routing traffic correctly without altering your global routing configuration.
Troubleshooting Common MikroTik Traceroute Issues
Because traceroute relies on fragile network protocols (ICMP and UDP) that are frequently restricted by security policies, you will regularly encounter anomalous results. Here is how to diagnose and resolve them.
1. The Output Shows 100% Packet Loss/Timeout Across All Hops
If you initiate a trace and every single hop (including the first hop) immediately shows 100% loss or timeout, but your LAN clients can access the internet without issues, your router's security configuration or NAT stack is likely dropping the traffic.
- Firewall Filter Drop Rules: Check your
/ip firewall filterrules. If you have a strict drop rule in theoutputchain (traffic originating from the router itself) or theinputchain (incoming traffic destined for the router), the diagnostic packets or their returning ICMP "Time Exceeded" replies are being blocked. Add an explicit permit rule for ICMP:/ip firewall filter add chain=input protocol=icmp action=accept comment="Allow incoming ICMP for traceroute and ping replies" - NAT / Masquerading Issues: Traffic generated by the router itself must be translated (src-nat) to your public WAN IP when heading out. If your masquerade rules are bound strictly to specific subnets rather than the WAN interface, local router-originated traceroute packets will go out with private IPs, causing transit providers to drop them on return. Ensure your masquerade rule is set up like this:
/ip firewall nat add chain=srcnat out-interface=ether1-WAN action=masquerade
2. Intermediate Hops Show 100% Loss, But Subsequent Hops Work
A common point of confusion is seeing a specific intermediate hop (e.g., Hop 4) display 100% loss, while Hop 5, Hop 6, and the final destination show 0% loss.
- Why it happens: This is a normal phenomenon. Generating an ICMP "Time Exceeded" packet requires processing from a router's main CPU. To prevent Denial of Service (DoS) attacks and preserve resources, transit providers configure core routers to deprioritize or completely ignore TTL-expired packets.
- The Solution: If subsequent hops respond normally with acceptable latency, there is no network issue. Your packets are traversing the "silent" router without any performance degradation. Real packet loss is only occurring if the loss percentage persists from a specific hop all the way to the final target.
3. The Trace Abruptly Halts (The "5-Timeout" Limit)
In RouterOS, the traceroute utility has a built-in safety limitation: if five consecutive hops fail to respond (5 consecutive timeouts), the trace automatically terminates.
- The Issue: Many modern ISPs and cloud providers (such as Amazon AWS, Cloudflare, or corporate MPLS networks) pass packets through wide, private core networks that completely drop ICMP traffic. If you hit a stretch of six silent hops, your MikroTik traceroute will stop probing entirely, leaving you unable to see the remaining hops or the final destination.
- The Workaround: Since this 5-timeout limit is hardcoded into RouterOS, you must run your diagnostics from a connected client device (such as a Windows or Linux PC). Operating systems like Windows (
tracert) do not stop after 5 timeouts and will continue tracing up to their maximum TTL limit (usually 30 hops), bypassing the quiet segment. Alternatively, try toggling the traceroute protocol from UDP to ICMP, as some firewalls block UDP traceroute ports but permit standard ICMP pings.
Practical Scripting: Automating Traceroute on WAN Failures
When troubleshooting unstable WAN gateways, capturing a traceroute at the exact moment of a connection drop is invaluable. This script uses Netwatch to monitor a gateway, executes a traceroute to a target (like Google DNS) when a failure is detected, and saves the output to a text file on the router's storage.
Step 1: Create the Diagnostic Script
Go to System > Scripts and add a new script named wan_diagnostic_trace. Paste the following code:
# MikroTik Script: Auto-Traceroute on WAN Failure
:local target "8.8.8.8"
:local wanName "ether1-WAN"
:local logName "wan_fail_report"
:log warning "WAN Connection ($wanName) is DOWN! Initiating diagnostic traceroute to $target..."
# Run a traceroute with 10 packets and write to disk
/execute script={/tool traceroute $target count=10} file=$logName
:log info "Diagnostic traceroute completed. Output saved to $logName.txt"
Step 2: Link the Script to Netwatch
Configure Netwatch to monitor a public IP. If the IP becomes unreachable, Netwatch will automatically execute your script:
/tool netwatch add host=8.8.8.8 interval=10s down-script="/system script run wan_diagnostic_trace"
When your primary ISP drops, the router will capture the packet path and write it to disk. You can download the resulting wan_fail_report.txt file via WinBox or FTP to attach to your ISP support ticket, providing proof of exactly where the connection broke.
Frequently Asked Questions (FAQ)
Why does my MikroTik traceroute run continuously instead of stopping?
Unlike traditional operating systems that send exactly three packets and stop, MikroTik's traceroute behaves like an MTR tool. It runs continuously to measure real-time latency variations and jitter. To stop a running trace in the CLI terminal, press Ctrl + C. To run a trace with a set limit, use the count parameter (e.g., /tool traceroute 8.8.8.8 count=10).
Can I perform a traceroute to a domain name on my MikroTik router?
Yes, you can input a domain name (like google.com) into both WinBox and the CLI. However, for this to work, you must ensure your router has functional upstream DNS servers configured under /ip dns. If DNS is not configured, the router will fail to resolve the hostname and throw an invalid address error.
How do I traceroute out of a specific WAN port on RouterOS v7?
In modern RouterOS v7 (v7.21+), you must use the percent symbol in the target address field. For example, to force a traceroute out of physical port ether1, execute: /tool traceroute 8.8.8.8%ether1.
What is the difference between ICMP and UDP in the traceroute options?
ICMP traceroute uses standard Echo Requests (ping packets). UDP traceroute sends UDP probes to high, randomized ports. Since many firewalls block random incoming UDP traffic, ICMP traceroutes are generally much more successful and less prone to false timeout readings.
Why does MikroTik traceroute show 100% loss but my PC traceroute works?
This is typically caused by a firewall rule dropping traffic on the router's local output chain, or because you lack a working masquerade (NAT) rule covering traffic initiated by the router itself. Ensure you have a firewall rule allowing the router to receive ICMP packets on the input chain so it can process incoming TTL-expired packets.
Conclusion
The MikroTik traceroute tool is one of the most powerful utilities in RouterOS for checking path consistency, analyzing latency, and diagnosing routing loops. By mastering both the graphical WinBox interface and the fast-paced terminal CLI, you can diagnose complex network pathing issues in seconds. Keep in mind the unified @ and % syntax modifications when upgrading to the latest versions of RouterOS v7 to ensure your multi-WAN and VRF troubleshooting commands continue to run seamlessly.








