MikroTik RouterOS Torch: Real-Time Traffic Monitoring
MikroTik RouterOS Torch: Real-Time Traffic Monitoring
Section titled “MikroTik RouterOS Torch: Real-Time Traffic Monitoring”RouterOS Version: 6.x / 7.x Difficulty: Beginner Estimated Time: 15 minutes
Overview
Section titled “Overview”Torch is a real-time traffic monitoring tool that shows you exactly what’s flowing through your router’s interfaces. Unlike packet sniffers that capture data for later analysis, Torch displays live traffic statistics organized by protocol, IP address, port, MAC address, VLAN, or DSCP - giving you instant visibility into your network’s behavior.
Use Torch when you need to:
- Identify what’s consuming bandwidth
- Find which hosts are generating traffic
- Discover unknown or suspicious connections
- Debug connectivity issues
- Verify traffic is flowing through expected paths
Key insight: Torch shows traffic before firewall filtering. This means you’ll see packets that get dropped by firewall rules, which is useful for debugging but can be confusing if you expect to only see allowed traffic.
Accessing Torch
Section titled “Accessing Torch”WinBox
Section titled “WinBox”Navigate to Tools > Torch, select an interface, configure filters, and click Start.
Command Line
Section titled “Command Line”/tool torch interface=ether1Press Ctrl+C to stop.
WebFig
Section titled “WebFig”Navigate to Tools > Torch, configure options, and click Start.
Basic Usage
Section titled “Basic Usage”Monitor All Traffic on Interface
Section titled “Monitor All Traffic on Interface”/tool torch interface=ether1Example Output:
MAC-PROTOCOL IP-PROTOCOL SRC-ADDRESS DST-ADDRESS TX-RATE RX-RATEip tcp 192.168.1.100 142.250.185.206 1.2Mbps 156kbpsip tcp 192.168.1.100 151.101.1.140 89kbps 1.8Mbpsip udp 192.168.1.100 8.8.8.8 2kbps 2kbpsip icmp 192.168.1.50 8.8.8.8 1kbps 1kbpsMonitor with Specific Columns
Section titled “Monitor with Specific Columns”/tool torch interface=ether1 src-address=0.0.0.0/0 dst-address=0.0.0.0/0 port=anyFiltering Options
Section titled “Filtering Options”Torch supports multiple filter parameters to focus on specific traffic:
| Parameter | Description | Example |
|---|---|---|
interface | Interface to monitor (required) | ether1, bridge1 |
src-address | Filter by source IP | 192.168.1.0/24 |
dst-address | Filter by destination IP | 8.8.8.8 |
src-address6 | Filter by source IPv6 | 2001:db8::/32 |
dst-address6 | Filter by destination IPv6 | 2001:4860:4860::8888 |
port | Filter by port number | 80, 443, 53 |
ip-protocol | Filter by IP protocol | tcp, udp, icmp |
mac-protocol | Filter by MAC protocol | ip, arp, ipv6 |
vlan-id | Filter by VLAN tag | 100 |
dscp | Filter by DSCP value | 46 |
Common Monitoring Scenarios
Section titled “Common Monitoring Scenarios”Find Top Bandwidth Users
Section titled “Find Top Bandwidth Users”Monitor LAN interface to see which hosts use the most bandwidth:
/tool torch interface=bridge-lanSort results by TX or RX rate to identify heavy users.
Monitor Specific Host
Section titled “Monitor Specific Host”Track all traffic to/from a particular device:
/tool torch interface=bridge-lan src-address=192.168.1.100Monitor Web Traffic Only
Section titled “Monitor Web Traffic Only”Filter for HTTP and HTTPS:
/tool torch interface=ether1-wan port=80,443 ip-protocol=tcpMonitor DNS Queries
Section titled “Monitor DNS Queries”/tool torch interface=bridge-lan port=53 ip-protocol=udpMonitor VoIP Traffic
Section titled “Monitor VoIP Traffic”Filter for SIP and RTP:
/tool torch interface=ether1 port=5060,10000-20000 ip-protocol=udpMonitor IPv6 Traffic
Section titled “Monitor IPv6 Traffic”/tool torch interface=ether1 mac-protocol=ipv6Monitor Specific VLAN
Section titled “Monitor Specific VLAN”/tool torch interface=ether1 vlan-id=100Monitor by DSCP (QoS)
Section titled “Monitor by DSCP (QoS)”Check traffic with specific QoS markings:
/tool torch interface=ether1 dscp=46Output Fields
Section titled “Output Fields”| Field | Description |
|---|---|
MAC-PROTOCOL | Layer 2 protocol (ip, arp, ipv6, etc.) |
IP-PROTOCOL | Layer 3/4 protocol (tcp, udp, icmp, etc.) |
SRC-ADDRESS | Source IP address |
DST-ADDRESS | Destination IP address |
SRC-PORT | Source port number |
DST-PORT | Destination port number |
TX-RATE | Transmit rate (data leaving the interface) |
RX-RATE | Receive rate (data entering the interface) |
TX | Total bytes transmitted |
RX | Total bytes received |
VLAN-ID | VLAN tag if present |
DSCP | DSCP value |
SRC-MAC | Source MAC address |
DST-MAC | Destination MAC address |
Verification Examples
Section titled “Verification Examples”Check 1: Verify Internet Traffic Flowing
Section titled “Check 1: Verify Internet Traffic Flowing”/tool torch interface=ether1-wan dst-address=8.8.8.8Expected: Should show traffic when clients access internet.
Check 2: Identify Unknown Traffic
Section titled “Check 2: Identify Unknown Traffic”/tool torch interface=bridge-lanExpected: Review for unexpected protocols or destinations.
Check 3: Verify VLAN Traffic Separation
Section titled “Check 3: Verify VLAN Traffic Separation”/tool torch interface=ether1 vlan-id=100Expected: Only traffic tagged with VLAN 100.
Troubleshooting
Section titled “Troubleshooting”Problem: “TX shows 0 but RX shows traffic”
Section titled “Problem: “TX shows 0 but RX shows traffic””Cause: Hardware offloading is enabled on a bridge, bypassing software processing.
Solution:
- Check bridge settings:
/interface bridge settings print
- Disable hardware offloading if you need full Torch visibility:
Or on the specific bridge:/interface bridge settings set use-ip-firewall=yes/interface bridge set bridge1 fast-forward=no
Note: Disabling hardware offloading reduces performance. Only do this for troubleshooting.
Problem: “Can’t see traffic between wireless clients”
Section titled “Problem: “Can’t see traffic between wireless clients””Cause: Client-to-client forwarding happens without going through the router CPU.
Solution: This is expected behavior. Traffic between wireless clients with forwarding enabled doesn’t pass through Torch. To monitor, you’d need to disable client-to-client forwarding (not recommended for production).
Problem: “Torch shows traffic but firewall should block it”
Section titled “Problem: “Torch shows traffic but firewall should block it””Cause: Torch displays traffic before firewall processing.
Solution: This is normal behavior. Torch shows all incoming packets regardless of firewall rules. Use firewall logs or connection tracking to verify what’s actually allowed.
Problem: “High CPU usage when running Torch”
Section titled “Problem: “High CPU usage when running Torch””Cause: Torch is CPU-intensive, especially on busy interfaces.
Solution:
- Apply filters to reduce processed traffic
- Run Torch for short periods only
- Avoid running on high-throughput interfaces during peak times
- Use specific filters rather than monitoring all traffic
Problem: “Missing some traffic types”
Section titled “Problem: “Missing some traffic types””Cause: Bridge hardware offloading or fast-forward enabled.
Solution: For complete visibility:
/interface bridge set bridge1 fast-forward=noRemember this impacts performance.
Common Pitfalls
Section titled “Common Pitfalls”1. Expecting Torch to Show Only Allowed Traffic
Section titled “1. Expecting Torch to Show Only Allowed Traffic”Wrong assumption: “Torch shows what’s passing through my network”
Reality: Torch shows traffic before firewall filtering. Dropped packets still appear.
2. Running Torch Without Filters on Busy Interface
Section titled “2. Running Torch Without Filters on Busy Interface”Wrong:
/tool torch interface=ether1-wan # On a 1Gbps linkRight: Apply filters to reduce load:
/tool torch interface=ether1-wan src-address=192.168.1.1003. Forgetting Hardware Offloading Limitations
Section titled “3. Forgetting Hardware Offloading Limitations”Problem: Only seeing partial traffic on bridge interfaces.
Check:
/interface bridge settings printIf use-ip-firewall=no, bridged traffic bypasses CPU and Torch.
4. Confusing TX and RX Direction
Section titled “4. Confusing TX and RX Direction”Remember:
- TX = Traffic going OUT of the interface (transmit)
- RX = Traffic coming INTO the interface (receive)
On a WAN interface:
- RX = Downloads (data from internet)
- TX = Uploads (data to internet)
On a LAN interface:
- TX = Downloads (data to client)
- RX = Uploads (data from client)
5. Leaving Torch Running in Background
Section titled “5. Leaving Torch Running in Background”Torch continuously uses CPU resources. Always stop it when done:
- WinBox: Click Stop
- CLI: Press
Ctrl+C
Use Cases
Section titled “Use Cases”Bandwidth Hog Detection
Section titled “Bandwidth Hog Detection”Find which device or service is consuming bandwidth:
/tool torch interface=bridge-lanLook for high TX/RX rates and identify the source address.
Security Monitoring
Section titled “Security Monitoring”Identify suspicious connections:
/tool torch interface=ether1-wanLook for:
- Unexpected destination IPs
- Unusual ports
- High traffic volumes from single hosts
QoS Verification
Section titled “QoS Verification”Verify traffic is marked correctly:
/tool torch interface=ether1 dscp=46Should show only VoIP or priority traffic.
Troubleshooting Connectivity
Section titled “Troubleshooting Connectivity”Verify traffic is reaching the router:
/tool torch interface=ether2 src-address=192.168.1.100If client traffic appears but connectivity fails, the issue is likely routing or firewall, not Layer 2.
Limitations
Section titled “Limitations”- No historical data - Torch shows real-time only; no logging or graphs
- CPU intensive - High resource usage on busy interfaces
- Hardware offloading blind spots - Bridge fast-forward traffic invisible
- Wireless client-to-client - Not visible with forwarding enabled
- No payload inspection - Shows metadata only, not packet contents
- Pre-firewall view - Shows dropped traffic too
Related Topics
Section titled “Related Topics”Traffic Analysis
Section titled “Traffic Analysis”- Bandwidth Test - throughput measurement
- Packet Sniffer - full packet capture
- Netwatch - host monitoring
Troubleshooting
Section titled “Troubleshooting”- Firewall Basics - verify firewall isn’t blocking
- NAT Masquerade - check NAT translations
- Static Routes - verify routing
- Simple Queues - bandwidth limiting
- Firewall Mangle - traffic classification