MTR Network Diagnostic

Server assisted New Internet & Network

MTR combines traceroute and ping: it probes every hop on the path several times, so each hop gets a loss percentage and a best, average and worst round trip. This tool runs it from up to 10 Globalping community probes in the regions you choose, finds where loss that reaches the destination really begins, and also reads an mtr --report pasted from your own computer. The probes measure, not your computer.

Privacy: The host and options you enter are sent from the Mutqan server to Globalping, a public measurement network whose volunteer probes run the test. Globalping publishes measurement parameters and results, so do not enter anything private. Mutqan stores nothing.

How do you read an MTR report?

MTR repeats traceroute probes many times and reports, for every hop, the share of probes lost and the best, average and worst round trip. Start from the destination: loss there is what traffic experiences; loss at a middle hop that does not continue to the hops after it is a router rate-limiting its ICMP replies (RFC 1812), while loss that starts at one hop and persists to the end marks where packets are really dropped.

How to use MTR Network Diagnostic

  1. Enter the host, choose a probe region or up to five locations, and set the probes and the packets per hop (5 by default).
  2. Keep ICMP, or switch to TCP with the service port when the destination answers ICMP slowly or not at all.
  3. Press Run MTR. Compare the Paths by probe table first: loss at the destination in one region only points at that region’s path.
  4. For your own connection, run mtr --report (or WinMTR on Windows), paste the report, optionally type the host above, and press Analyze pasted report.

MTR Network Diagnostic features

  • MTR from up to 10 Globalping probes: every hop probed 1 to 16 times, with loss, replies and best, average and worst round trip
  • A diagnosis per probe that separates ICMP rate limiting at a middle hop from loss that continues to the destination, and names the hop where real loss begins
  • ICMP, UDP or TCP probes, so a destination that rate-limits ICMP can be measured on its service port instead
  • Paths by probe: hops, target reached, loss at the destination and its average round trip, side by side for every region
  • A paste box for mtr --report, mtr -rw or mtr -rwz output from your own machine, analyzed in the browser
  • Per-hop table as CSV and every probe’s raw output as text

Inputs and outputs

Inputs

  • Host name or IP address (public targets only), probe region or up to five locations, probes (1–10), packets per hop (1–16), protocol (ICMP, UDP, TCP) and the port for UDP or TCP.
  • Or a pasted mtr report (mtr --report, -rw, -rwz with AS numbers); the host field, if filled, helps confirm the last hop, because an mtr report does not print its target.

Outputs

  • Summary: probes that reached the target, worst loss at the destination, best destination average and packets per hop (paste mode: format, hops, target reached, loss and average at the last hop).
  • Paths by probe and the per-hop table: host, address, loss, replies, average, best and worst round trip.
  • Diagnosis per probe, the Globalping measurement record and the raw output of every probe.

MTR Network Diagnostic example

Analyze a pasted mtr report to dns.google

Input:

Host: dns.google
HOST: laptop                       Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                0.0%    10    0.6   0.7   0.5   1.1   0.2
  2.|-- 100.64.0.1                 0.0%    10    4.1   4.4   3.8   6.0   0.6
  3.|-- ???                       100.0    10    0.0   0.0   0.0   0.0   0.0
  4.|-- 172.253.66.108             0.0%    10   38.2  38.6  37.9  40.1   0.7
  5.|-- dns.google                 0.0%    10   38.9  39.0  38.4  40.3   0.6

Output:

Detected format: mtr · Hops: 5 · Target reached: yes (dns.google) · Loss at the last hop: 0% · Last hop average: 39 ms
Findings:
- The target answered at hop 5 (average 39 ms).
- Hops 1, 2 use private or carrier-grade NAT addresses: your router and the ISP’s access network before the public Internet.
- Loss at hop 3 does not continue to later hops: those routers rate-limit their ICMP replies; it is not real packet loss.
- Hop 3 never answers (it forwards traffic but does not send TTL-exceeded messages); harmless when later hops respond.

How to read the MTR Network Diagnostic results

Look at the destination row first. 0% loss there means the path delivers traffic, whatever the middle hops show.

Loss that starts at one hop and stays at a similar level to the destination is real and begins at that hop or on the link just before it. Loss at a single middle hop only is ICMP rate limiting.

A large gap between best and worst at the destination, with a low best, is jitter: congestion or queueing somewhere on the path. A high best is distance.

??? rows are hops that never answered; they are harmless when the hops after them answer.

When to use MTR Network Diagnostic

  • Gathering evidence for an ISP or hosting ticket: which hop starts the loss, from which regions, with a measurement ID they can check.
  • Checking whether intermittent call or game lag from a region is loss on the path or jitter at the destination.
  • Comparing a path over ICMP and over TCP 443 to prove that apparent loss is only ICMP being deprioritised.
  • Reading an mtr report a colleague or customer sent, with the rate-limiting cases already explained.

Troubleshooting

  • All hops after the first few show ???: the probe’s network or the destination filters the probe type. Run again with TCP and the service port.
  • Loss only at the destination while the service works: the server rate-limits ICMP replies. Measure with TCP to the service port to confirm.
  • The measurement comes back partial: with many packets per hop a probe may not finish within the waiting time; use fewer packets or probes.
  • "This text does not look like an mtr report": paste the whole report with the HOST header line and every hop line, as mtr printed it.

Frequently asked questions about MTR Network Diagnostic

What does MTR show that traceroute does not?

Traceroute sends a few probes per hop once; MTR keeps probing every hop and keeps statistics, so each hop gets a loss percentage, a best, average and worst round trip and, on a terminal, the standard deviation. That turns a one-off path into evidence of where loss and jitter start.

A middle hop shows 60% loss but the destination shows 0%. Is something wrong?

No. That router limits how many ICMP replies it sends about expired packets, while it forwards your traffic normally. Only loss that continues from a hop all the way to the destination is real; the diagnosis names the hop where such loss begins.

How many packets per hop should I send?

Five is a sensible default here: it finishes within the time a measurement may take and shows loss of 20% or more. For a ticket to an ISP, send 10 to 16 packets, or run mtr on your own machine for 100 cycles and paste the report.

Can I run MTR from my own computer on this page?

No, a web page cannot send the probes MTR needs, so the probe mode runs on Globalping probes in the regions you choose. Install mtr (Linux, macOS) or WinMTR (Windows), run a report and paste it into the box: it is analyzed in your browser and not uploaded.

Why does the last hop show loss when the website works?

Some servers rate-limit ICMP replies to themselves too. If the website loads normally, run the measurement again with TCP to port 443: TCP probes are answered by the network stack like real connections and show whether traffic is really being lost.

Are MTR results public?

In probe mode, yes: Globalping keeps the target, options and results of every measurement readable by anyone with its ID. A pasted report stays in your browser.

Technical notes

MTR sends probes with increasing TTL like traceroute and repeats them in cycles; for every hop it counts the probes sent and the replies, and keeps the last, average, best and worst round trip. Loss is the share of probes without a reply, the one-way loss idea of RFC 7680 applied to a round trip.

Intermediate routers answer from their control plane and may rate-limit ICMP (RFC 1812 §4.3.2.8), so the diagnosis only treats loss as real when it persists to the destination, and reports the first hop of such a run.

Probe mode asks Globalping for an mtr measurement with the packets per hop you chose; the Mutqan server polls it for up to 20 seconds and returns each hop’s answered round trips and Globalping’s loss figure.

Limitations and methodology

Probe mode measures from Globalping community probes in the chosen locations, not from your computer; your own path may differ. Paste your own mtr report to analyze it.

At most 16 packets per hop, which detects loss of a few percent or more but not rare drops; a long mtr run from your own machine is more sensitive.

The probe mode table shows each hop’s answered round trips and loss as reported by Globalping; standard deviation and AS numbers are not returned in this view.

MTR shows the forward path only, and load-balanced paths can mix routers in one hop.

Security and privacy

Probe mode sends the host and options from the Mutqan server to Globalping, where they and the results are public to anyone with the measurement ID. Mutqan stores nothing.

A pasted report is analyzed in your browser and never uploaded, even though it may contain your local addresses.

References