Care to elaborate?
Packet traces do not lie, per se, but they represent only a certain perspective. More perspectives are needed for problems to come into focus.
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.
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.
https://movingpackets.net/2017/10/06/misinterpreting-tracero... (discussion at https://news.ycombinator.com/item?id=15474043 )
"Great tool for misleading results." -> the results the tool provides are either mostly misleading (many are misleading), or are in large part misleading (a large part of each is misleading), potentially both
"Traceroute is easy to be misinterpreted" -> the results the tool provides are easy to misinterpret
"They are only misleading if you allow yourself to be misled by them" -> the results the tool provides require expertise to interpret, implying that otherwise they're (largely) misleading - the same thing the person said right above you
This is turning into a "well I like it and it has its place". Cool, it's just not what was being argued.
Recently my mother felt misled by a car commercial. Her position was that saying things like "under this many years or that many miles" is misleading, because it suggests that it's a set of options she can pick from (which of course ended up not being the case).
Unfortunately for her, this is a natural language construct - whether she understands it correctly or not depends on how aligned her common sense regarding it is with people at large. She understood it differently and thus felt misled. But you may notice that ultimately it was her own mistaken understanding of the common parlance that misled her. So when she said this was misleading the only thing I could reasonably say was exactly this. That I did not find the phrasing misleading, and I'm sorry she'd been misled by it (irrespective of whether that was on her or on the world, as that doesn't really matter).
It's completely on people how they want to handle this. You can find people being misled by stuff like this to be unreasonable and just tell them so, or you can put out a disclaimer regardless. Depends completely per case. This goes all the way to having multiple mechanical interlocks at places with heavy duty xray sources, or preferring machine checked memory management.
The other issue with packet loss is the tool doesn’t handle ICMP properly in the first place. A ping flood to an end to end host like 1.1.1.1 shows 0% loss, but when I use mtr to do flood like pinging it shows my wifi router with 100% loss. If I ping flood my router I get 0%.
It’s genuinely a bad tool and you should really just be keeping ping and traceroute separate as they do completely different things.
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.
An argument could be made for a device configured as such to show loss on ping but not on mtr if you configure the rate limits so that the icmp reply rate is lower than ttl expired rates. Which tool would be wrong than? Would you blame ping for producing misleading results?
The running counters and the ability to pick out the obvious rate limiting when the loss doesn't cascade into the hops to me is akin to traceroutes * * * output. It doesn't always mean that the packets are blackholed, connectivity is broken, it just means the tool is producing an artifact due to network configuration or network characteristics. Further investigation is needed to figure out what's going on.
MTR imho is giving you much more insight into the network than traceroute or ping separately. It doesn't resolve the usual firewall/rate limiting artifacts, but gives you way more information about paths if you know how to interpret them.
I'm not sure I understand what you're saying, but in this case control-plane packet rates are different for generating TTL exceeded vs Echo Response, where one is giving 80% loss and the other is giving 0% loss at similar rates. Gripe #1 why are we even testing control plane in the first place, it's a useless metric that doesn't have utility at measuring end to end latency/loss.
> An argument could be made for a device configured as such to show loss on ping but not on mtr if you configure the rate limits so that the icmp reply rate is lower than ttl expired rates. Which tool would be wrong than? Would you blame ping for producing misleading results?
Sure that would be a problem, but any combination could be misleading if the data path is yielding 0% loss for high rates of ICMP end to end. This is why it's not a very particularly helpful metric and can be downright misleading (usually not to me, but I've seen plenty people make incorrect inferences from bunk MTR results because the tool isn't intuitive).
> The running counters and the ability to pick out the obvious rate limiting when the loss doesn't cascade into the hops to me is akin to traceroutes * * * output. It doesn't always mean that the packets are blackholed, connectivity is broken, it just means the tool is producing an artifact due to network configuration or network characteristics. Further investigation is needed to figure out what's going on.
Sure that's great, not particularly helpful to the masses who misunderstand the tool. I worked as a network engineer for a decade receiving bunk MTR reports where people freak out because they're seeing "packet loss" which was inexistent on the data forwarding plane (you know the one that actually matters).
> MTR imho is giving you much more insight into the network than traceroute or ping separately. It doesn't resolve the usual firewall/rate limiting artifacts, but gives you way more information about paths if you know how to interpret them.
Time shouldn't be wasted measuring the control path and then investigating to confirm it is the control path and not data path. You cannot make these mistakes using traceroute and ping separately because traceroute doesn't have a notion of a "per-hop" loss indicator and ping doesn't involve intermediate hops (unless an intermediate hop generates an ICMP diagnostic for an echo request).
Understanding can be improved. Bunk MTRs are easy to spot. You tell them this is not an issue because .... . Than they will learn and usually that customer will stop sending you bunk MTRs.
I'm pretty sure that the people that are opening tickets with providers/network teams because they have nothing better to do is nearing 0. The fact that they ran an MTR shows that they were doing some troubleshooting and at the end of the day a problem needs to be solved. It may not be on your end but that needs to be investigated but the same would apply for a crappy iperf throughput test. IMHO Any clue/information into where that problem is, is helpful. You may need to filter relevant from irrelevant.
But if I get to pick one out of 2 problems, one has a crappy iperf results, the other has an MTR that has a loss that carries over, I would probably pick the second because that at least gives me indication on whereabouts should I start looking.
> Time shouldn't be wasted measuring the control path and then investigating to confirm it is the control path and not data path. You cannot make these mistakes using traceroute and ping separately because traceroute doesn't have a notion of a "per-hop" loss indicator.
traceroute does have per-hop indicator, it's the * in the output, it's just so often off that nobody pays much attention. You can't really catch issues that are related to route-flaps or reroutes with traceroute. with MTRs it becomes pretty clear if a reroute happens in the middle of your test. I guess you can keep running traceroute but I will leave it to you to sift through the output of that nightmare and than it effectively became MTR, with worse output.
There are also many options available in MTR that is not there in traceroute (to trigger these packets by tcp or udp packets), fix local or remote port etc. Even if you just run it with 3 packets per hop, you will have way more options. You don't have to use it as a continuous monitor to indicate packetloss but can give you the traceroute level information in a much cleaner format and you have more options to choose from.
> ping doesn't involve intermediate hops (unless an intermediate hop generates an ICMP diagnostic for an echo request).
ICMP echo requests and replys can be subject to different QoS treatment as TCP/UDP traffic, so that also doesn't necessarily gives you the right idea when testing for end to end connectivity issue. Iperf imho is the best bet, and if you want to be really accurate you pick the src/dst port for client/server just to be sure you get into the same Class as your problematic traffic.
As a sidenote MTR packets are also ride the data-plane until they reach the TTL=1.