When a problem is "the app is slow" or "the phone drops calls," counters and logs run out of answers and you need to see the actual packets. RouterOS gives you two ways: a switch-chip port mirror for line-rate SPAN into a real analyser, and a built-in sniffer that streams straight into Wireshark. The Cisco SPAN & RSPAN post, in RouterOS.
There are two fundamentally different ways to capture on RouterOS, and picking the wrong one wastes an afternoon. The switch-chip port mirror copies frames from one port to another entirely in hardware — line-rate, zero CPU cost, but blind to anything the switch chip doesn't see and only as flexible as the chip allows. The software sniffer (/tool sniffer) runs on the CPU: hugely flexible filtering, can capture the router's own traffic, and can stream live to Wireshark — but it costs CPU and can drop packets under heavy load.
Rule of thumb: mirror when you need every packet at wire speed into a dedicated analyser (matching Cisco SPAN); sniff when you need clever filters or want the capture on your laptop right now. Both map to Cisco IOS: SPAN & RSPAN Port Mirroring — hardware SPAN vs the flexibility of capturing on-box.
01
The zero-overhead option. Tell the switch chip to copy everything on a source port to a target port where your analyser (or a laptop running Wireshark) is plugged in.
> /interface ethernet switch print # confirm the box has a switch chip # Copy all traffic seen on the source port to the target port. # The analyser on ether5 sees a faithful copy at line rate, no CPU hit. > /interface ethernet switch set [find] mirror-source=ether3 mirror-target=ether5 # Some chips split direction: mirror-egress-target / mirror-ingress for # per-direction capture. Check what YOUR model exposes before assuming.
The mirror-target port becomes a capture-only port — it feeds copied frames out and shouldn't carry normal traffic, exactly like a Cisco SPAN destination. Don't mirror to a port that's also a live uplink or a bridge member, or you'll get confusing double traffic and possibly a loop. Dedicate the target port to the analyser. And remember the switch chip only sees what's switched in hardware — traffic the CPU handles (some routed or VLAN paths on certain models) won't appear; that's the sniffer's job.
02
When you want "just the VoIP between the phone and the PBX" and nothing else, the CPU sniffer's filters earn their keep. Capture to memory or a file, then read it back.
# Narrow the capture before starting — filters keep CPU and noise down. > /tool sniffer set filter-interface=vlan50-voip \ filter-ip-address=10.10.50.0/24 filter-port=sip \ file-name=voip.pcap file-limit=10000KiB > /tool sniffer start # ...reproduce the problem... > /tool sniffer stop > /tool sniffer packet print # quick look on-box # Then drag voip.pcap off with WinBox and open it in Wireshark.
03
The best of both: the sniffer's filtering with a live view on your laptop. RouterOS wraps captured packets in TZSP and sends them to a host where Wireshark decodes them in real time.
> /tool sniffer set streaming-enabled=yes streaming-server=10.10.99.10 \ filter-interface=ether3 filter-stream=yes > /tool sniffer start # On 10.10.99.10, run Wireshark with a capture filter 'udp port 37008' # — it auto-decapsulates TZSP and you watch the packets live. # Stop it when done; streaming costs CPU on the router. > /tool sniffer stop
These are the exact capabilities the offensive side abuses once it's on a box — a compromised RouterOS with the sniffer streaming is passive interception of everything crossing it. That's why the hardening pass locks down management access: the sniffer is a gift to whoever controls the router. Legitimately, it's the fastest way to end a "the network is broken" argument with a packet capture. Know it does both.
Takeaways
NOCTIS diagnoses the hard ones on MikroTik and Cisco across Crete — packet-level capture and analysis that turns "it's just slow sometimes" into a root cause and a fix.
Book a Discovery Call →