MikroTik CLI Troubleshooting: Advanced Diagnostic Techniques

WinBox shows you what a router looks like. The CLI shows you what a router is doing. When a ticket says “the network is slow” or “it works sometimes,” the GUI runs out of answers fast — the CLI does not.

This guide covers advanced diagnostic techniques on RouterOS: a troubleshooting methodology, resource and process analysis, live traffic tools, packet capture, log analysis, connection tracking, routing diagnostics, and scripted automation for problems that only show up at 3 AM.

Table of Contents

1. A Troubleshooting Methodology for RouterOS
2. Step 1: Check System Resources
3. Step 2: Find the Process Eating CPU
4. Step 3: Check Interface Health
5. Step 4: Watch Live Traffic with Torch
6. Step 5: Capture Packets for Deep Analysis
7. Advanced Ping and Traceroute Techniques
8. Reading the Connection Tracking Table
9. Diagnosing Routing Problems
10. Log Analysis and Extended Logging
11. Netwatch: Continuous Host Monitoring
12. Scripting Automated Diagnostics
13. Wireless-Specific Diagnostics
14. Common Symptoms and Where to Look
15. Quick-Reference Command Cheat Sheet
16. Conclusion

A Troubleshooting Methodology for RouterOS

Random command-running wastes time. Work through a fixed sequence instead:

1. Define the problem. Write down what is happening and what should happen instead. Vague reports (“slow,” “broken”) need a concrete symptom before any command helps.
2. Gather data. Pull resource stats, interface counters, and logs before forming a theory. Guessing first biases what you look for next.
3. Form a hypothesis. Match the symptom to a likely layer: physical link, IP addressing, routing, firewall, or application.
4. Test systematically. Change one variable at a time. Isolate whether the problem sits on the router, the link, or the remote endpoint.
5. Work bottom-up. Start at the physical layer and move up. A flapping interface explains packet loss faster than a firewall rule audit does.

Step 1: Check System Resources

Always start here. Resource exhaustion causes symptoms that look like routing or firewall problems but are neither.

/system resource print
/system resource cpu print
/system resource irq print
/disk print

• CPU load — sustained load above 80% on any core points to a process problem, not necessarily a traffic problem. RouterOS commonly runs single-threaded for certain features, so one maxed core with others idle is a real finding, not noise.
• Free memory — low free memory on boards with small RAM can cause dropped connections and failed script execution before it causes an outright crash.
• Disk usage — a full disk blocks logging and can prevent configuration saves. Check this before assuming a config change silently failed.

Step 2: Find the Process Eating CPU

High CPU alone does not tell you the cause. The Profiler tool breaks usage down by process:

/tool profile

Read the output for:

• Which process consumes the most CPU — common offenders are the firewall, queueing, routing protocol daemons (OSPF, BGP), and DNS.
• Per-core distribution — on multi-core boards, a single busy core with others idle usually means a feature that does not scale across cores (some firewall configurations, certain queue types).

If firewall or routing shows up as the top consumer, the fix is architectural: reduce rule count, use address lists instead of long rule chains, or use FastTrack/FastPath where the setup supports it.

Step 3: Check Interface Health

/interface print stats
/interface print status
/interface monitor-traffic ether1

• Error counters — rising rx-error or tx-error values point to a cabling, duplex mismatch, or SFP problem, not a configuration issue.
• Link status flapping — check /log print where topics~"link" for repeated up/down transitions. Flapping links cause routing protocol churn that looks like a routing bug from the outside.
• FastTrack/FastPath counters — confirm whether traffic is hitting the fast path. Traffic falling back to the slow path under load is a common, easy-to-miss cause of throughput drops.

Step 4: Watch Live Traffic with Torch

Torch shows live traffic per interface, broken down by source, destination, port, and protocol:

/tool torch interface=ether1
/tool torch interface=ether1 port=443
/tool torch interface=ether1 src-address=10.0.0.0/24

Critical detail: Torch shows traffic before firewall filtering. A packet visible in Torch may still be dropped by a firewall rule further down the chain. Do not treat Torch visibility as proof that traffic is reaching its destination — pair it with connection tracking or a packet capture to confirm the full path.

Step 5: Capture Packets for Deep Analysis

When Torch is not enough — protocol-level detail, intermittent issues, or security investigation — capture packets directly:

# Capture to memory (quick look)
/tool sniffer quick interface=ether1

# Capture to a file for Wireshark
/tool sniffer set file-name=capture filter-interface=ether1 file-limit=10000KiB
/tool sniffer start
... reproduce the issue ...
/tool sniffer stop
/file print

Download the resulting file and open it in Wireshark for full protocol decoding. RouterOS also supports streaming captures live to a running Wireshark instance over the network — useful when a physical capture file transfer is impractical:

/tool sniffer set streaming-enabled=yes streaming-server=192.168.1.50
/tool sniffer start

Note: Captures held in RouterOS memory are retained for a limited window (around 10 minutes) before rotating out. For intermittent problems, capture to a file instead of relying on memory retention.

Advanced Ping and Traceroute Techniques

Ping does more in RouterOS than most engineers use it for:

/ping 8.8.8.8 count=100 size=1472 do-not-fragment
/ping 8.8.8.8 interval=100ms count=50
/ping 8.8.8.8 src-address=10.0.0.1

• size=1472 do-not-fragment — tests the maximum MTU that passes without fragmentation. Essential for diagnosing PPPoE, VPN tunnel, or ISP MTU mismatches that cause large packets to silently fail while small ones succeed.
• interval=100ms — a fast ping burst reveals jitter and intermittent loss that a default one-second interval smooths over.
• src-address= — forces the ping to originate from a specific interface or IP, useful for testing policy routing or multi-WAN setups where the default route does not reflect the path you intend to test.

Traceroute reveals where a path breaks or where latency spikes:

/tool traceroute 8.8.8.8
/tool traceroute 8.8.8.8 use-dns=no
/tool traceroute 8.8.8.8 protocol=udp

Switch protocol=udp or protocol=tcp when ICMP-based traceroute gets blocked partway through the path — a common occurrence past the network edge.

Reading the Connection Tracking Table

The connection tracking table shows every active session the firewall is aware of — essential for diagnosing NAT problems and firewall rule mismatches:

/ip firewall connection print
/ip firewall connection print count-only
/ip firewall connection print where dst-address~"203.0.113.5"

• Connection count near max-entries — a table filling up drops new connections outright. Check /ip firewall connection tracking print for the configured maximum and current usage.
• Unexpected NAT translations — filter by destination address to confirm a specific NAT rule is actually firing, rather than assuming from the rule list alone.
• Connection state stuck — connections stuck in a non-established state for an unusually long time often point to asymmetric routing, where reply traffic takes a different path than the original request.

Diagnosing Routing Problems

/ip route print detail
/ip route print where dst-address=203.0.113.0/24
/routing bgp session print
/routing ospf neighbor print

• Missing route — confirm the route exists before checking anything else. A route that never installed points to the routing protocol or static configuration, not the firewall.
• Route with wrong distance — two routes to the same destination with different administrative distances can silently prefer the wrong path. Sort by distance to catch this.
• BGP or OSPF session down — check the session state directly rather than assuming a routing protocol issue from missing routes alone. A down session explains missing routes completely; a routing filter issue does not show up the same way.
• Route flapping — repeated route withdrawal and re-announcement in the logs points to an unstable link or a misconfigured protocol timer, not a firewall or NAT problem.

Log Analysis and Extended Logging

Default logging misses most of what you need for a real investigation. Enable topic-specific logging before the problem happens again, not after:

/system logging add topics=firewall action=memory
/system logging add topics=dhcp action=memory
/system logging add topics=bgp action=memory
/system logging add topics=snmp action=memory

/log print where topics~"firewall"
/log print where time>[/system clock get time]-01:00:00

• Enable logging on suspected components only. Logging everything at debug level buries the real signal and can affect performance on lower-end hardware.
• Match log action to retention needs. memory logging is fast but clears on reboot; use disk or remote syslog for anything that needs to survive a restart or be correlated later.
• Correlate timestamps across sources. A firewall log entry and an interface flap entry at the same second are rarely a coincidence.

Netwatch: Continuous Host Monitoring

For intermittent problems that vanish before you can capture them live, Netwatch runs continuous probes and reacts automatically:

/tool netwatch add host=8.8.8.8 type=icmp interval=10s \
  up-script={:log info "8.8.8.8 is up"} \
  down-script={:log info "8.8.8.8 is DOWN"}

• Probe types — Netwatch supports ICMP, TCP, HTTP, DNS, and simple ping probes, so you can monitor application-layer reachability, not just basic ping.
• Trigger scripts on state change — pair a down-script with a diagnostic script (see the next section) to capture data automatically the moment a problem starts, instead of waiting for a human to notice.
• VRF and link-local support — Netwatch works across VRFs and with link-local IPv6 addresses, useful for monitoring internal infrastructure that is not globally routable.

Scripting Automated Diagnostics

Intermittent problems that happen once a week at 3 AM need automated capture, not a human watching a terminal. Build a diagnostic script and trigger it from a scheduler or a Netwatch down-script:

/system script add name=diagnostics source={
  :log info "Starting diagnostics"
  :log info "System resources:"
  /system resource print
  :log info "Interface status:"
  /interface print status
  :log info "Routing table:"
  /ip route print
  :log info "Active connections:"
  /ip firewall connection print count-only
  :log info "DNS status:"
  /tool dns-lookup name=google.com
}

Schedule it to run on an interval, or trigger it directly from a Netwatch down-script for event-driven capture:

/system scheduler add name=hourly-diag interval=1h on-event=diagnostics

Extend the script with a packet capture trigger for the most persistent intermittent issues — a scripted /tool sniffer start tied to a Netwatch down-script catches the exact packets around the failure, instead of relying on being logged in when it happens.

Wireless-Specific Diagnostics

Wireless problems need their own set of checks, separate from wired diagnostics:

/interface wireless registration-table print detail
/interface wireless print stats

• CCQ (Client Connection Quality) — closer to 100% is better. Below 60% indicates a poor link worth investigating further.
• Signal strength (TX/RX) — roughly 0 to -45 dBm is excellent, -55 to -75 dBm is acceptable, and below -75 dBm should be treated as effectively no link.
• Signal-to-noise ratio — a low SNR with strong signal strength points to interference, not distance. Check for overlapping channels or nearby noise sources before assuming a hardware or placement problem.

Common Symptoms and Where to Look

Symptom	Check First
“Network is slow” (vague report)	/tool profile, then /interface print stats for error counters
Works, then randomly drops	/log print where topics~"link" for flapping, plus Netwatch for pattern capture
Large downloads fail, small pages work	MTU — test with /ping size=1472 do-not-fragment
Some traffic reaches destination, some does not	Connection tracking table for asymmetric routing or NAT mismatch
Routing table missing expected route	/routing bgp session print or /routing ospf neighbor print before assuming a filter issue
Wireless clients disconnect randomly	Registration table for CCQ and SNR, not just signal strength alone
Config seems to “not save”	/disk print — a full disk blocks config writes silently on some builds

Quick-Reference Command Cheat Sheet

# Resources and processes
/system resource print
/tool profile

# Interfaces
/interface print stats
/interface monitor-traffic ether1

# Live traffic (pre-firewall)
/tool torch interface=ether1

# Packet capture
/tool sniffer set file-name=capture filter-interface=ether1
/tool sniffer start
/tool sniffer stop

# MTU test
/ping 8.8.8.8 size=1472 do-not-fragment

# Connection tracking
/ip firewall connection print count-only

# Routing
/ip route print detail
/routing bgp session print

# Logging
/system logging add topics=firewall action=memory
/log print where topics~"firewall"

# Continuous monitoring
/tool netwatch add host=8.8.8.8 type=icmp interval=10s

Conclusion

Advanced RouterOS troubleshooting is not about knowing more commands — it is about running them in the right order. Check resources first, confirm the process consuming them second, then move layer by layer from the physical interface up to routing and application traffic. Torch and the connection tracking table answer most day-to-day questions. Packet capture and scripted diagnostics handle the intermittent problems that disappear before you can look at them directly. Build the diagnostic script once, and the next 3 AM ticket writes its own evidence before you even log in.

---

Check our list of MikroTik guides