Packet loss reported “through the MikroTik” is not yet a diagnosis. The dropped packets may originate on the client, an Ethernet cable, a wireless link, the router’s interface queue, an overloaded CPU, an upstream circuit, or the destination itself. A remote hop may also rate-limit ICMP while forwarding normal traffic correctly.
The reliable approach is to measure the path in segments, preserve interface counters, and change one variable at a time.
Start with a Simple Path Map
Write down the actual path before changing RouterOS:
test client → access switch/AP → MikroTik LAN → MikroTik WAN → ISP gateway → internet target
Record the client IP, LAN gateway, WAN interface, ISP next hop, and one stable external IP. Use IP addresses during the first tests so DNS is not confused with packet loss.
Also record the current RouterOS version and export the configuration with sensitive fields hidden:
/system resource print
/system package print
/export hide-sensitive file=before-packet-loss-check
The export is a rollback and comparison aid, not a substitute for a binary RouterOS backup. Protect both files because network configurations contain internal addressing and other operational details.
Run Four Pings at the Same Time
From a wired client, continuously test:
- the client’s local gateway;
- the ISP next hop, if it responds;
- a stable external IP;
- the application destination.
On Windows, use separate terminals:
ping -t 192.0.2.1
ping -t 198.51.100.1
ping -t 1.1.1.1
ping -t example.com
The documentation addresses above are placeholders; replace the first two with your real gateway and ISP hop.
RouterOS has its own Ping tool. Test from the router as well:
/ping 1.1.1.1 count=100 interval=200ms
Interpret the combined result:
| First place loss appears | Most likely investigation area |
|---|---|
| Client to LAN gateway | Client NIC, cable, switch/AP, LAN interface, local congestion |
| Router to external IP, but not LAN gateway | WAN interface, modem/ONT, ISP circuit, routing |
| Only one distant hop | Remote ICMP policy or destination path; verify application traffic |
| Client loses packets but router does not | LAN side or router forwarding/queue/CPU path |
| Both client and router lose at the same time | WAN/upstream path or router resource issue |
Do not infer the cause from a five-packet sample. Run long enough to capture the reported event and compare timestamps.
Use Traceroute Carefully
RouterOS Traceroute reveals the routed hops toward a destination:
/tool traceroute 1.1.1.1
A hop showing loss does not automatically drop transit traffic. Routers often deprioritise or rate-limit their own ICMP replies. It is meaningful when loss begins at a hop and continues through every later responsive hop, especially when end-to-end application tests degrade at the same time.
Route changes can also make hop comparisons misleading. Repeat the test and correlate it with the four simultaneous pings.
Check Physical and Interface Counters
Look for errors, drops, link flaps, and negotiation problems before editing firewall rules:
/interface print detail
/interface print stats-detail
/interface ethernet print stats
/log print where topics~"interface"
RouterOS documents general counters under Interface stats and monitor-traffic. Important clues include increasing receive/transmit errors, FCS errors, alignment errors, link downs, and tx-queue-drop.
Take two counter snapshots separated by the failure interval. A large lifetime counter is less useful than a counter that increments exactly when users report loss.
For a suspect Ethernet port:
/interface ethernet monitor ether1 once
Confirm expected rate, full duplex, and link state. If errors rise, replace the patch cable and test the device on a known-good port before forcing speed or duplex. Manual negotiation settings can create a new mismatch, so use them only when both ends are configured deliberately.
Monitor current traffic without resetting anything:
/interface monitor-traffic ether1
Compare the observed rate with the interface capacity and with queue drops. A link can be saturated even when the five-minute average looks modest.
Check CPU, Memory, and Per-Process Load
An overloaded router may forward inconsistently even though the interfaces look clean:
/system resource print
/tool profile
Run /tool profile during the incident. Look for sustained CPU saturation and the process consuming it—firewall, management, networking, encryption, or another service. A brief spike during a diagnostic command is not enough evidence.
Common causes include expensive firewall logging, large connection tracking tables, queues that exceed the hardware’s capacity, traffic inspection, VPN encryption beyond the CPU’s practical throughput, and management tools polling too frequently.
Check connection tracking only if it is relevant to the path:
/ip firewall connection tracking print
/ip firewall connection print count-only
Do not flush the table as a diagnostic shortcut on a production router. That disrupts active sessions and destroys evidence.
Inspect Queues and Congestion
Packet loss during heavy upload often comes from a full upstream queue rather than a defective line. Review both simple queues and queue trees:
/queue simple print stats
/queue tree print stats
Watch whether drops increase during the complaint. If the WAN is slower than the Ethernet link to the modem, the bottleneck may be outside the RouterOS-visible queue. A deliberate shaping policy slightly below measured circuit capacity can move the queue to a place you control, but only after repeatable capacity tests.
Do not add multiple overlapping queue systems at once. FastTrack can bypass some queueing and accounting paths; understand the current packet flow before changing it.
Test MTU Without Guessing
An MTU problem often looks selective: small pings work, while large transfers, particular sites, or VPN traffic stall. MikroTik’s Layer 2 misconfiguration guidance notes that frames exceeding L2MTU can be silently dropped.
Test progressively sized packets with fragmentation prohibited where the path and RouterOS command support it:
/ping 1.1.1.1 size=1400 do-not-fragment=yes count=20
/ping 1.1.1.1 size=1472 do-not-fragment=yes count=20
For IPv4 over a standard 1500-byte path, a 1472-byte ICMP payload plus 28 bytes of IPv4 and ICMP headers totals 1500 bytes. PPPoE, tunnels, VLAN combinations, and other encapsulation may require a smaller payload or appropriate MSS handling.
Do not lower every interface MTU until packets happen to pass. Identify which encapsulation adds overhead and set MTU/L2MTU/MSS at the correct boundary.
Separate Wireless Loss from Router Loss
Repeat the same test from a wired client. If wired traffic is clean, investigate signal strength, noise, channel utilisation, roaming, retries, and the access point rather than the WAN firewall.
For MikroTik wireless packages, the available monitoring commands depend on the driver family and hardware. Use the interface’s current RouterOS documentation instead of copying legacy /interface wireless commands onto a device that uses the newer WiFi menus.
Check Routing and Gateway Health
Unexpected failover or a flapping default route can create intermittent loss:
/ip route print detail where dst-address=0.0.0.0/0
/routing route print detail where dst-address=0.0.0.0/0
/log print where topics~"route|netwatch"
Confirm distance, routing table, gateway status, and any recursive-check design. If scripts or Netwatch alter routes, correlate their log timestamps with the outage. A single ICMP target is a fragile basis for failover because the target or an intermediate path may rate-limit it.
Change One Thing and Re-Test
Once the evidence points to a layer, make the smallest reversible change: replace one cable, move one port, pause one nonessential high-cost rule, correct one MTU boundary, or test a known-good upstream device. Repeat the exact same measurements.
A reboot may temporarily clear resource pressure or a driver state, but it also resets useful counters and hides the trigger. Export logs and counters first. If loss returns after the same uptime or traffic pattern, the reboot was a symptom reset, not a fix.
The final incident record should say where loss first appeared, which counters changed, whether the router itself lost packets, what load was present, what single change was made, and whether the same controlled test improved. That is enough to distinguish a RouterOS problem from a cable, radio, capacity, or upstream failure without guessing.
