Version: 7.25

Torch

CLI reference:/tool/torch

Torch shows the traffic that passes one interface right now. It groups the packets into flows, one row for each combination of addresses, protocol, ports and DSCP value, and shows the rate of each flow in both directions. Use it to find out who uses a link, which protocols run over it, or whether the packets of a connection arrive at all.

Torch sees received packets before the firewall filters them, so traffic that a firewall rule drops still appears on the interface it arrives on. Packets the router sends are counted as they leave, so traffic dropped in the forward chain does not appear on the outgoing interface. While Torch runs, the router turns IP fast path and FastTrack off, as it does for the packet sniffer; on a busy router the CPU load rises for that time. To see the contents of packets or save them to a file, use the packet sniffer instead.

Torch runs until you stop it with Control+C. To stop it after a set time, add duration, for example duration=10s.

Watch the video about Torch.

See what passes an interface

Give Torch the interface to watch. The interface name can be given without interface=:

/tool/torch bridge

Columns: MAC-PROTOCOL, IP-PROTOCOL, DSCP, SRC-ADDRESS, SRC-PORT, DST-ADDRESS, DST-PORT, TX, RX, TX-PACKETS, RX-PACKETS
MAC-PROTOCOL  IP-PROTOCOL  DSCP  SRC-ADDRESS    SRC-PORT  DST-ADDRESS   DST-PORT        TX         RX         TX-PACKETS  RX-PACKETS
ip            icmp            0  192.168.88.21            192.168.88.1                  197.3kbps  197.3kbps          48          48
ip            tcp             0  192.168.88.20     58910  192.168.88.1  2000 (btserv)   1152bps    1152bps             2           2
ip            udp             0  192.168.88.20      2257  192.168.88.1  2001 (glimpse)  2.0Mbps    0bps              172           0

The table updates every second until you stop Torch. In this example, 192.168.88.21 pings the router, and 192.168.88.20 runs a bandwidth test in which it receives 2 Mbps from the router.

Each row is one flow between two addresses:

SRC-ADDRESS and SRC-PORT - The address and port on the far side of the interface: the side whose traffic the interface receives. This holds even when the router started the conversation, and for traffic that the router forwards.
DST-ADDRESS and DST-PORT - The other end of the flow. Port numbers are shown with their service names, such as 2000 (btserv).
RX - The rate of the traffic that the interface receives from SRC-ADDRESS, in bits per second.
TX - The rate of the traffic that the interface sends towards SRC-ADDRESS, in bits per second.
TX-PACKETS and RX-PACKETS - The same two directions in packets per second.

A column appears only when a flow has a value for it: the port columns appear only when TCP or UDP flows are present.

Find the host that uses the bandwidth

On the LAN interface, SRC-ADDRESS is the LAN host, so TX is what the host downloads and RX what it uploads. The rows with the highest rates show who uses the connection. A host with many connections, such as a web browser, has many rows; filter by its address to see them together. Watch the LAN interface, not the WAN interface: after source NAT, the flows on the WAN interface have the router's public address instead of the hosts' addresses.

To watch one host, filter by its address:

/tool/torch bridge src-address=192.168.88.21/32

Columns: MAC-PROTOCOL, IP-PROTOCOL, DSCP, SRC-ADDRESS, DST-ADDRESS, TX, RX, TX-PACKETS, RX-PACKETS
MAC-PROTOCOL  IP-PROTOCOL  DSCP  SRC-ADDRESS    DST-ADDRESS   TX         RX         TX-PACKETS  RX-PACKETS
ip            icmp            0  192.168.88.21  192.168.88.1  197.3kbps  197.3kbps          48          48

The address filters match the columns as Torch shows them: src-address matches SRC-ADDRESS, the far side of the interface, and dst-address matches DST-ADDRESS. On a LAN interface, filter the hosts with src-address; dst-address set to a LAN host usually matches nothing there. For IPv6, use src-address6 and dst-address6.

Watch one protocol or port

To show only one IP protocol or one port, use ip-protocol and port:

/tool/torch bridge ip-protocol=tcp port=443

port matches either SRC-PORT or DST-PORT. It takes one port or any; a list such as port=80,443 fails with expected end of command. The port filter applies only to flows that have ports: flows without ports, such as ICMP, still appear with a port filter.

Check VLAN tags and DSCP marking

On an interface that carries tagged VLANs, Torch adds a VLAN-ID column for the tagged traffic. To check that traffic arrives in the right VLAN with the right DSCP value, for example voice traffic in VLAN 99 with DSCP 46 (Expedited Forwarding), watch the parent interface. In this example, a test ping marked with DSCP 46 runs in VLAN 99:

/tool/torch ether1

Columns: VLAN-ID, MAC-PROTOCOL, IP-PROTOCOL, DSCP, SRC-ADDRESS, DST-ADDRESS, TX, RX, TX-PACKETS, RX-PACKETS
VLAN-ID  MAC-PROTOCOL  IP-PROTOCOL  DSCP  SRC-ADDRESS   DST-ADDRESS   TX         RX         TX-PACKETS  RX-PACKETS
     99  ip            icmp           46  198.51.100.1  198.51.100.2  237.3kbps  235.7kbps          48          48
         ip            icmp            0  203.0.113.1   203.0.113.2   120.5kbps  120.5kbps          48          48

The first row is tagged with VLAN 99 and marked with DSCP 46; the second row is untagged. vlan-id=99 or dscp=46 shows only the matching flows. On the VLAN interface itself, the frames are already untagged, so the VLAN-ID column does not appear there. For an untagged device, such as a phone on a bridge port, watch the bridge and filter by the phone's address, for example src-address=192.168.88.30/32.

The DSCP value is part of a flow, so when the two directions of a conversation are marked differently, they show as two rows: one with only RX and one with only TX. Here the requests arrive with DSCP 46 and the answers leave with DSCP 0:

/tool/torch ether1

Columns: MAC-PROTOCOL, IP-PROTOCOL, DSCP, SRC-ADDRESS, DST-ADDRESS, TX, RX, TX-PACKETS, RX-PACKETS
MAC-PROTOCOL  IP-PROTOCOL  DSCP  SRC-ADDRESS  DST-ADDRESS  TX         RX         TX-PACKETS  RX-PACKETS
ip            icmp            0  203.0.113.1  203.0.113.2  165.6kbps  0bps               50           0
ip            icmp           46  203.0.113.1  203.0.113.2  0bps       165.6kbps           0          50

Torch does not show the VLAN priority (PCP) of the frames; use the packet sniffer to check it.

See traffic that the firewall drops

Torch counts packets before the firewall, so it shows traffic that a firewall rule drops. In this example, a rule in the input chain drops the pings from 192.168.88.21:

/tool/torch bridge src-address=192.168.88.21/32

Columns: MAC-PROTOCOL, IP-PROTOCOL, DSCP, SRC-ADDRESS, DST-ADDRESS, TX, RX, TX-PACKETS, RX-PACKETS
MAC-PROTOCOL  IP-PROTOCOL  DSCP  SRC-ADDRESS    DST-ADDRESS   TX    RX         TX-PACKETS  RX-PACKETS
ip            icmp            0  192.168.88.21  192.168.88.1  0bps  197.3kbps           0          48

The requests arrive (RX), and the router sends nothing back (TX is 0). The same picture, with traffic in one direction only, also shows a connection whose replies take another path or never come, so check the counters of the rule itself to confirm that it drops the traffic: /ip/firewall/filter/print stats (see Filter).

See which CPU handles the traffic

On routers with several CPUs, cpu=any adds a CPU column, with one row for each CPU that handled packets of a flow. Use it to see whether one heavy flow keeps a single CPU busy:

/tool/torch bridge cpu=any

Columns: CPU, MAC-PROTOCOL, IP-PROTOCOL, DSCP, SRC-ADDRESS, DST-ADDRESS, TX, RX, TX-PACKETS, RX-PACKETS
CPU  MAC-PROTOCOL  IP-PROTOCOL  DSCP  SRC-ADDRESS    DST-ADDRESS   TX         RX         TX-PACKETS  RX-PACKETS
  0  ip            icmp            0  192.168.88.20  192.168.88.1  170.3kbps  389.3kbps          21          48
  0  ip            icmp            0  192.168.88.21  192.168.88.1  201.4kbps  201.4kbps          49          49
  1  ip            icmp            0  192.168.88.20  192.168.88.1  32.4kbps   0bps                4           0
  3  ip            icmp            0  192.168.88.20  192.168.88.1  186.5kbps  0bps               23           0

Here the router's pings to 192.168.88.20 leave from CPUs 0, 1 and 3, and the replies are received on CPU 0.

Technical details

Fast path

While Torch runs, the router turns IP fast path and FastTrack off for all traffic, not only on the watched interface. Both come back on when Torch stops.

Traffic that Torch does not see

Torch sees the packets that reach the router's CPU on the watched interface:

On a bridge with hardware offloading, the switch chip forwards traffic between ports without the CPU, so Torch does not see it. Unknown unicast, broadcast and some multicast traffic still reach the CPU and remain visible. See Packet flow with hardware offloading and MAC learning.
With L3 hardware offloading, routed traffic that the switch chip forwards does not reach the CPU either.
Unicast traffic between wireless clients with client-to-client forwarding enabled is not visible to Torch.

Torch shows protocols and IP addresses, not MAC addresses. To find the MAC address of a host, see its lease in the DHCP server.

For all parameters, see /tool/torch in the CLI reference.

See what passes an interface​

Find the host that uses the bandwidth​

Watch one protocol or port​

Check VLAN tags and DSCP marking​

See traffic that the firewall drops​

See which CPU handles the traffic​

Technical details​

Fast path​

Traffic that Torch does not see​