6 ms·

Care to elaborate?

by otterz 2y ago

Care to elaborate?

lode 2y ago
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-traceroute/ https://movingpackets.net/2017/10/06/misinterpreting-tracero... (discussion at https://news.ycombinator.com/item?id=15474043 https://news.ycombinator.com/item?id=15474043 )
- oxygen_crisis 2y ago
  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.
  - perching_aix 2y ago
    None of these claims are mutually exclusive with one another. "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.
    - ta1243 2y ago
      You can claim pretty much any tool is misleading then. If you don't know how curl works, with say following links, it's "misleading".
      - perching_aix 2y ago
        Yes, you can. It's basically a terminal case of something being unintuitive. Whether something is misleading is in the eye of the beholder. 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.
zinekeller 2y ago
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.
- crims0n 2y ago
  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 2y ago
    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 2y ago
    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.
- tristor 2y ago
  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.
commandersaki 2y ago
The packet loss indicator is the biggest issue I have. I’m well aware that routers may deprioritise ICMP and lead to packet loss, and therefore if you’re not seeing cascading packet loss then it’s probably phantom. Also what really matters is end to end loss anyways. 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.
- Elixir6419 2y ago
  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.
  - commandersaki 2y ago
    mtr -i 0.1 1.1.1.1 gives 80% loss for my router (ok not the same as 100% loss as I stated earlier, but I just rerun to experiment), which is deprioritising ttl exceeded packets, but a ping -c 1000 -f 192.168.0.1 (my router) yields 0% loss. The per hop loss indicator is not only incorrect but also isn't useful even if it were accurate since end to end loss is what matters, not a phantom per hop loss that doesn't have any effect on end to end loss.
    - Elixir6419 2y ago
      Right, so control-plane packet rates are rate limited (to some definition of sane), but they are applied to all applications, traceroutes, pings alike. 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.

Care to elaborate?

by otterz 2y ago

Care to elaborate?

lode 2y ago

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-traceroute/ https://movingpackets.net/2017/10/06/misinterpreting-tracero... (discussion at https://news.ycombinator.com/item?id=15474043 https://news.ycombinator.com/item?id=15474043 )

oxygen_crisis 2y ago
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.
- perching_aix 2y ago
  None of these claims are mutually exclusive with one another. "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.
  - ta1243 2y ago
    You can claim pretty much any tool is misleading then. If you don't know how curl works, with say following links, it's "misleading".
    - perching_aix 2y ago
      Yes, you can. It's basically a terminal case of something being unintuitive. Whether something is misleading is in the eye of the beholder. 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.

zinekeller 2y ago

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.

crims0n 2y ago
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 2y ago
  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 2y ago
  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.
tristor 2y ago
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.

commandersaki 2y ago

The packet loss indicator is the biggest issue I have. I’m well aware that routers may deprioritise ICMP and lead to packet loss, and therefore if you’re not seeing cascading packet loss then it’s probably phantom. Also what really matters is end to end loss anyways. 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.

Elixir6419 2y ago
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.
- commandersaki 2y ago
  mtr -i 0.1 1.1.1.1 gives 80% loss for my router (ok not the same as 100% loss as I stated earlier, but I just rerun to experiment), which is deprioritising ttl exceeded packets, but a ping -c 1000 -f 192.168.0.1 (my router) yields 0% loss. The per hop loss indicator is not only incorrect but also isn't useful even if it were accurate since end to end loss is what matters, not a phantom per hop loss that doesn't have any effect on end to end loss.
  - Elixir6419 2y ago
    Right, so control-plane packet rates are rate limited (to some definition of sane), but they are applied to all applications, traceroutes, pings alike. 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.