[HN Gopher] MTR: 'traceroute' and 'ping' in a single tool
___________________________________________________________________
MTR: 'traceroute' and 'ping' in a single tool
Author : program
Score : 88 points
Date : 2025-02-03 22:26 UTC (2 days ago)
(HTM) web link (www.bitwizard.nl)
(TXT) w3m dump (www.bitwizard.nl)
| eudhxhdhsb32 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| wrigby wrote:
| > Is it indicating that the router is faster at forwarding
| packets than responding to ping requests?
|
| Exactly this. In most "real" routers, forwarding (usually)
| happens in the "data plane". It's handled by an ASIC that has a
| routing table accessible to it in RAM. A packet comes in on an
| interface, a routing decision is made, and it goes out another
| interface - all of this happens with dedicated hardware. Pings
| (ICMP Echo requests), however, get forwarded by this ASIC to a
| local CPU, where they are handled by software (in the "control
| plane").
|
| You're really seeing different response times from the two
| control planes - one may be more loaded or less powerful than
| another, regardless of the capacity of their data planes.
| linsomniac wrote:
| This is also why you may see packet loss at one particular
| hop but then responses from hops beyond it. The hop with
| packet loss in this case probably has an overwhelmed CPU,
| rather than indicating that a particular network link has
| packet loss. mtr reporting packet loss at a hop is only
| reliable if every hop after it has similar packet loss.
|
| Maybe the only thing I've explained more in my career than
| this is why it's ok that your Linux box has no "free" memory.
| p_ing wrote:
| This is always worth a (re)read to understand traceroute:
|
| https://archive.nanog.org/sites/default/files/traceroute-201...
| Bluecobra wrote:
| ^ This should be required reading for anyone using
| traceroute.
| rixed wrote:
| > Is it indicating that the router is faster at forwarding
| packets than responding to ping requests?
|
| I believe most of the time this is the reason indeed. Answering
| an ICMP error to a TTL expiration or to an echo request is very
| low priority.
|
| This latency in error message generation may even be a better
| signal of the router load than the latency of the actualy trip
| through it.
| toast0 wrote:
| Most likely, it's as you described, router N forwards packets
| much faster than it generates icmp ttl exceeded, and router N+1
| is nearby and generates icmp faster.
|
| However, it could also be the case that the routing back to you
| is significantly different, so you can have a much longer path
| to you from router N than router N+1.
|
| This is more likely to happen on routes that cross oceans. Say
| you're tracing from the US to Brazil. If router N and N+1 are
| both in Brazil, but N sends return packets through Europe and
| N+1 sends through Florida, N+1 returns will arrive
| significantly sooner.
| commandersaki wrote:
| Great tool for misleading results.
| otterz wrote:
| Care to elaborate?
| lode wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| Hikikomori wrote:
| 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.
| ta1243 wrote:
| 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 wrote:
| 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.
| mschuster91 wrote:
| > 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.
| neom wrote:
| I once interviewed the manage who built MSN messenger -
| and when I asked her what the most important thing to the
| growth was, she said it needed to be able to punch
| through NATs so kids could use it at high school and uni,
| because that was the segment they were trying to get it
| to take off in. (and from what I recall, that strategy
| indeed worked quite well)
| tetha wrote:
| 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.
| hiAndrewQuinn wrote:
| >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!
| walrus01 wrote:
| the results aren't misleading, people just don't know how to
| read them, or understand why bidirectional traceroutes are
| necessary.
|
| https://www.youtube.com/watch?v=L0RUI5kHzEQ
| klysm wrote:
| Only misleading if you don't understand what it's doing. If you
| do, then it's a useful tool.
| neilv wrote:
| MTR has long been one of the first little tools that I install on
| workstations. sudo apt install mtr-tiny
|
| 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.
| jlmcguire wrote:
| MTR is a useful tool but it is a somewhat common source of
| illusory issues since it generates so many icmp time exceeded
| packets that routers stop replying to other folks running traces.
| It's important, as others said, to understand that these aren't
| testing the data path of a network but instead the control plane
| path.
___________________________________________________________________
(page generated 2025-02-05 23:02 UTC)