TORCH CONFUSION

RouterOS General
1

Dear Folk,

When using torch on an interface, the RX and TX data are clearly relative to that
interface and thus give you a proper direction of the packet travel.

However the SRC and DST arrangement of the IP’s in each connection seems arbitrary, confused irrelevant or all three.

Can someone please clarify for me what the meaning of src and dst are in a data table
that is showing a two way connection on a single line between points, and not a single packet as shown by
the packet sniffer wherein src and dst make absolute sense.

By the way I REALLY WISH that the packet sniffer could show translated data like tcpdump does. Looking at raw packet data is not fun. :slight_smile:


Thanks

Homer W Smith
CEO Lightlink Internet

2

OK, after many years of being confused by Torch, here is my analysis.

Torching any particular interface, the SRC address is src address of incoming packets to
the interface as is the Receive bytes.

The DST address is the src address for outgoing bytes as is the TX bytes.

SRC and DST seem backwards. RX and TX make sense.

SRC and DST are from the remote view point, RX/TX are from the tik’s viewpoint.

I am just a stoopid newbie, so maybe I don’t understand something.

Comments welcome.

Homer

3

Both term pairs are from the interface’s point of view.

The more confusing part is that you have packets that a router receives, as well as packets that the router sends, and “an interface’s point of view” includes packets regardless of their direction, so long as their are within the interface’s “view”.

A packet has a source and destination, and the router receives/sends each packet from a particular interface.

So, src-address is the IP address that sent the packet and dst-address is the IP meant to receive the packet (which will be the source for reply packets, IF there are any reply packets to begin with). Theoretically, a dst-address may not belong to your router, or be one your router knows the network of, and instead may be another one in your ISP’s network… in which case you’ll see the packet, but your router won’t react to it. It often simply so conveniently happens (thanks to your ISP) that the only packets you receive happen to be for your IP address(es).

AFAIK, RX is the rate at which bits are received from that interface, and TX is the rate at which bits are sent from that interface.

4

[quote=“boen_robot”]Both term pairs are from the interface’s point of view.

The more confusing part is that you have packets that a router receives, as well as packets that the router sends, and “an interface’s point of view” includes packets regardless of their direction, so long as their are within the interface’s “view”.]


Sorry I am either dense or still confused.

Say we have torched our default gateway ether 1 port, it shows

SRC 192.160.13.1 DST 209.150.235.122 TX 100 RX 500

Which is the remote IP and which is the local IP on the tik?

I can’t tell because packets are going both directions.

Since packets are going both directions on eth1, sometimes 192.160.13.1 is the SRC,
and sometimes 209.150.235.122 is the SRC.

So as far as I can tell SRC and DST are meaningless and change depending on which packet we are looking at, the incoming or the outgoing.

In particular the real question is WHICH IP IS REMOTE AND WHICH IP IS LOCAL?

If they had REMOTE for SRC, and LOCAL for DST, it would match up with what
I am seeing on our tiks, which is backwards from what I would have guessed.

The packet sniffer on eth1 shows:

tx 209.150.235.122 → 192.160.13.1
rx 192.160.13.1 → 209.150.235.122

THAT tells me remote is 192.160.13.1 and local is 209.150.235.122.

So why is 192.160.13.1 shown as SRC in torch?

Torch might be a lot more useful if it had two lines for each connection, thus
truly showing remote → local and local → remote. So this would look like:

SRC DST RX TX
192.168.31.1 209.150.235.122 500
209.150.235.122 192.168.13.1 100

It is fine to put them on one line, but then SRC and DST become ambiguous and
thus meaningless as they are only right half the time.

Homer

5

Say we have torched our default gateway ether 1 port, it shows

SRC 192.160.13.1 DST 209.150.235.122 TX 100 RX 500

Which is the remote IP and which is the local IP on the tik?

192.160.13.1 is the IP that sent the packet… If this packet is the start of a new connection that your router started, that would be its IP. If this packet is the start of a new connection that the remote device started, it would be its IP. In this case, let’s assume it’s the remote device (for the sake of the rest of the explanation).

209.150.235.122 is the IP that is meant to receive the packet. This may either be your router, a different device in the same local network as your router (if your ISP is dense enough to use Ethernet Hubs instead of Ethernet Switches), or it may be an IP from a different network that your ISP for whatever reason believes your router can forward to the device this IP actually belongs to.

If the destination IP is assigned to your router (or is an IP matching a destination in your “/ip route” list), the router will actually handle the packet, rather than just ignore it. If it ends up replying, it will send reply packet back to the remote device. The reply packet is seen in torch as
SRC 209.150.235.122 DST 192.160.13.1 TX 100 RX 500
since the new packet was sent by your router, and the intended receiver is the remote device.

6

[the destination IP is assigned to your router (or is an IP matching a destination in your “/ip route” list), the router will actually handle the packet, rather than just ignore it. If it ends up replying, it will send reply packet back to the remote device. The reply packet is seen in torch as
SRC 209.150.235.122 DST 192.160.13.1 TX 100 RX 500
since the new packet was sent by your router, and the intended receiver is the remote device.]

Sorry I guess I am really confused.

If someone at 192.160.13.38 opens a telnet session to our tik at 209.150.235.122, there will
be ONE torch line not two, that says

SRC 192.160.13.38 DST 209.150.235.122 The REMOTE is SRC

If someone on the tik opens a telnet to the remote site, again there will be ONE line that says

SRC 192.160.13.38 DST 209.150.235.122 The REMOTE is SRC

As far as I can see SRC means remote and DST means local, and there is only one
line in torch per two way connection, so src PACKET or dst PACKET is meaningless.

Am I making a total fool out of myself here?

Homer

7

OK, I did a little bit more extensive testing, and it seems what I’ve said above actually applies more specifically to the packet sniffer tool.

The torth tool on the other hand filters out ignored packets, as well as packets that come OUT of the interface, in favor of only showing non-ignored packets that come IN to the interface.

So, in essence, yes, the dst-address in torch is the IP that is either assigned to the router, or an IP that your router is able to route to.

If you point torch at your local interface, the dst-address will always be whatever IP your clients are looking for, be it your router’s IP, google’s or something else (since your router can route those packets), and if you point torch at your public interface, the dst-address will always be your router or (if your network is not NAT-ted) an IP of one of your clients.

8

I too think it is confusing. When you Torch an interface you would expect to sit at the router and look at the packet stream going out.
So “src” is the local side, “dst” is the remote side, “tx” is traffic transmitted on the interface and “rx” is traffic received on the interface.
So as it is now, “src” and “dst” are backwards and “tx” and “rx” are OK.

9

Torch is working on an interface and sees all the packets passing over it.

Address matching happens like this:

a) If you specify dst-address, then RX packets on interface should have this IP as destination;
b) If you specify dst-address, then TX packets on interface should have this IP as source.

Torch is designed in such way so you would be able to combine A and B and as a result see stream. You see actual traffic in both directions.

10

For now I am considering the situation where no matching criteria are specified.
Just observing the default output. When looking at the interface TX is seen as the output of the interface.
But then the traffic has src-address of the remote side and dst-address of the local side. That I would consider RX.

11

Thanks to all who replied. Here is my ‘rule’ that I learned.

If you are torching an interface, the remote IP on the same side of the router as the interface is always the source, and any other IP is the destination, whether it is inside the router or out another interface.

If packets are coming into and out of the same interface, then src becomes ambiguous, as both IP’s are
remote the the interface.

In any case I would have to complain that using src and dst in a one line description of a two way packets is inherently wrong and not useful, let alone easy to remember. Calling them remote and local might work except in the case where the packet comes in and out of the same interface.

Naming src and dst according to some ‘internal’ algorithm inside the router might make sense to the guys who wrote the code, but causes total consternation to tcpdump jockeys who already have an accepted definition of src and dst. The packet data itself SHOWS which IP is src and dst, so whatever torch is showing it is something other than simple accepted tcp/ip language. And its still not clear what that other is.

Homer W. Smith
CEO LIghtlink

12

Ten years later and Torch is still confusing. Does it filter out packets the router won’t process? Or does Torch show all packets crossing the Interface? Torch ignoring some packets could explain why I can’t find where some pings disappear.
As a user of Wireshark I got used to src and dst addresses meaning something about the headers of individual packets, not which side originated the connection.

13

Still confusing,

Can’t we add a feature request so that the traffic in TORCH be shown as it is being shown when you run the “Packet Sniffer” on the same interface and then see the results in .. say.. Wireshark ?

It is way too confusing and you’d need a manual to make some sense out of it !!!

PS: I specially created an account to comment on this forum although I’m a Mikrotik user in the past 10years-ish, I never was so frustrated with a feature as I’m with this one.

14

It would be nice if Torch showed the EST ( established flag ) for traffic.

Or is there another way to easily monitor interface traffic and filter established traffic verses non-established ( new connection ) traffic. ( and possibly other traffic type bits in the packet header ( such as current hop bit counters ).

North Idaho Tom Jones

15

It looks like torch uses features like “connection tracking” to show source and destination of traffic, and the source and destination address actually refer to the side that has made the L3 connection, not to the L2 traffic you are torching.
As such, it is difficult to predict what will be source and what will be destination when torching traffic on fully-routed interfaces.
On the typical “NAT router with a single internet connection” it is not that bad.

16

“source and destination address actually refer to the side that has made the L3 connection” - This makes sens. Yes, absolutely. I never thought from this perspective, I was so driven to see “traffic direction” that I missed this logic.