MTR: 'traceroute' and 'ping' in a single tool
14 comments
·February 3, 2025eudhxhdhsb32
Mtr is indeed nice.
One thing I've not understood is why will some hops have consistently lower ping times than hops farther down the chain in the same trace?
Is it indicating that the router is faster at forwarding packets than responding to ping requests?
oxygen_crisis
Traceroute doesn't use ping requests except with the old Windows binary. Usually it uses "Time-to-live (TTL) exceeded in transit" messages.
Beyond that technicality, your guess is often right... Routers will frequently prioritize forwarding packets over sending the TTL exceeded packets tools like MTR use to measure response times.
ta1243
Also you can easily have the TTL expired message going via a different route on the return path (and indeed the same applies with your normal connections, asymetric routing can be a pain - especially in networks with rpf issues (multicast ones are a particular pain point), and with stateful firewalls, but most of the time it's fine. You just need to be aware.
Obviously you know, but for anyone else reading, a modern traceroute tool (like mtr) can send icmp, udp or tcp, on generic or specific ports. Indeed the default for mtr on my laptop is to use icmp.
commandersaki
Great tool for misleading results.
ta1243
The results aren't misleading, shockingly large numbers of "computer professionals" have no idea how networks work, but that's because they can't use the tools rather than the tools being misleading
jeroenhd
People familiar with networking underestimate how complicated networking actually is. A huge segment of programmers will learn about the existence of routing and BGP and end up in a career where HTTPS and maybe DNS is all they need to worry about.
I'm 100% sure the only reason so many programmers know how NAT works is because NAT breaks video games.
hiAndrewQuinn
>shockingly large numbers of "computer professionals" have no idea how networks work
Incidentally, if you suspect you yourself are this, I can't recommend any book more highly than Michael W. Lucas's Networking for Systems Administrators. Don't be fooled by the title - the whole idea is to get you to the level where you can talk to a network engineer without looking totally clueless, and no farther - an excellent stopping point.
I would recommend it handily over, say, my own Intro to Networking class in college. And yes, `mtr` is mentioned by name in it!
otterz
Care to elaborate?
zinekeller
One under-appreciated problem (except from MPLS fudging and multiple load-balancing routers) is that traceroute (including MTR) only shows the way from the sender to the recipient, but actual networks, especially non-peered connections, usually do not use the same paths for both directions. One example that I've encountered is network A sending its packets via then-Telia (now Arelion) but network B routing their packets through NTT instead, which is only shown if you have initiated traceroutes in both directions.
lode
Traceroute is easy to be misinterpreted, because it does not have insight in underlying networks like MPLS, which could be the cause of issues.
https://movingpackets.net/2017/10/06/misinterpreting-tracero... (discussion at https://news.ycombinator.com/item?id=15474043 )
oxygen_crisis
They are only misleading if you allow yourself to be misled by them. It's an extremely informative measurement if you are aware of how it works and don't misinterpret the results.
MTR has long been one of the first little tools that I install on workstations.
I also have a hotkey to pop it up in a window, pinging to some host that'll always be somewhere on the other side of any ISP from me. Whenever I suddenly suspect a networking problem from my laptop, I hit the hotkey as the first troubleshooting step. MTR starts to narrow down a few different problems very quickly.