MTR: 'traceroute' and 'ping' in a single tool (opens in new tab)

I retract my previous statement about bad ICMP code (and other comments where I posted it). I was under the impression that mtr was actually doing ICMP echo requests to individual hops with decreasing TTLs, but it's just relying on the TTL being generated for the end to end echo request. However, this is just still a terrible indicator for packet loss, for example by wifi router heavily deprioritises generating TTL exceeded packets but will respond to a flood of echo requests no issue. My main contention is the per hop loss indicator is a useless and misleading metric and you should be measuring these things end to end with traceroute and ping separately.

EDIT: Re-Reading. I think I am some degree of a networker underestimating network complexity. I'll stand by that. Please make fun of me for only speaking in IPs and Ports.

Yeh. There is a very achievable level of knowledge about networking that's enough to make a lot of practical problems solvable.

Like, my practically acquired patchwork of knowledge about subnets, routing, some DNS, some VPN tech, maybe some ideas of masquerading and NAT'ing is easily enough to run a multi-site production environment across a number of networking stacks. And I wouldn't really call these things hard. I don't like people who are like "I don't know networking" once you say "routing table". The hardest part there is to understand how things are often a very large amount of very local decisions and a bunch of crossed fingers to get a packet from A to B. Oh an no one thinks about return paths until they run a site to site VPN.

But just a few steps beyond that is a cliff dropping into a terrifying abyss of complexity. LIke I know acronyms like BGP, CGNAT, ideas like Anycast DNS and kinda what they do, but it turns into very dark and different magik rather quickly. I say if we need that, we need a networker.

> I'm 100% sure the only reason so many programmers know how NAT works is because NAT breaks video games.

... and filesharing, from the days when bittorrent was huuuuge.

The way you write it makes it seems like you're blaming the tool for misleading results when that's the nature of traceroute itself.

MPLS don't have to hide routers though, up to the operator, even if they do it will give you idea of where things went wrong and you can contact the correct people. Load balancing links is either lacp or ecmp, first case doesn't really matter and in the second you'll just see multiple responses on a hop. Neither really had any impact on how useful traceroute is and doesn't really mislead.

It is possible to to reveal the impacts of asymmetric routing through other tools, for instance ThousandEyes can do this by performing a time synchronized bidirectional trace (among other things it can do that MTR cannot). This can be very valuable.

That said, in practice for the majority of end users, they will not be directly impacted by asymmetric routing, if only because so many services are now cloud-based and the major cloud devices are direct peered with all of the major ISPs at regional meeting points in most countries. As an example, on my connection in Denver on Comcast, going to most applications in AWS will enter the AWS network /in Denver/ and without traversing any transit provider, meaning effectively my traffic never goes across "the Internet", it goes from Comcast (my provider) directly to AWS (the provider for the application).

While it's always good to be mindful of the complexities of real-world routing, for the vast majority of common use cases now, entry-points to the target application are so widely distributed that the most impactful routing is inside the private network of the cloud provider, not across the larger Internet.

Disclaimer: Opinions are my own.

Which is why any network engineer worth their salt with ask for a trace in both directions (if available). Asymmetric routing can be an issue especially when going through stateful devices like firewalls.

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.

It's one of the best tools to troubleshoot packetloss on the internet and generally routed networks. It gives you way more information than ping or traceroute could potentially give.

If you run it in TCP or UDP mode you can even nail down the physical interface that's erroring in a LAG/LACP bundle due to being able to manipulate the 5 tuples very well.

I'm also curious about the flags you used for ping and mtr that showed you this discrapancy.

I tried mtr (I usually use ping and traceroute). 87% packet loss at my router and the next hop, then 0% loss. WTF I say to myself and uninstall.