[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.

[Hikikomori]

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.

[tristor]

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.

[crims0n]

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.

[RajT88]

Network engineers for most issues ask for traces on both sides of the connection.

Packet traces do not lie, per se, but they represent only a certain perspective. More perspectives are needed for problems to come into focus.

[tetha]

I'm not going to tell you how long I've at one time been searching for a missing route on the return path of a VPN connection... But damn the lights that went on when I realized that hurt by being too bright.