| |

LFCE 98 ๐Ÿง mtr โ€” Combining ping and traceroute

โฑ๏ธ Estimated read: 12 min | |

mtr is the diagnostic tool that combines the two functions that the previous chapters covered separately: the path discovery of traceroute and the continuous quality measurement of ping. The tool sends the ICMP echo requests with the incrementing TTL to discover the hops, and it sends them repeatedly to compute the loss and the latency statistics for each hop. The result is a per-hop view of the network quality that a single ping or a single traceroute cannot provide .

The previous chapters covered the connectivity testing with ping and traceroute; this chapter covers the tool that combines them into a continuous measurement. The LFCE exam expects the candidate to monitor and troubleshoot network performance, and mtr is the tool that answers the question “where on the path is the problem” rather than “is the destination reachable.”

Key point: The mtr has two interfaces: the interactive ncurses display and the report mode. The interactive display updates the statistics in real time, and the report mode (-r -c <N>) runs the specified number of cycles and prints the final table, which is the format for the scripting and the CI pipelines . The -n option disables the DNS resolution, which is faster and avoids the DNS queries from the measurement itself . The loss at an intermediate hop is often cosmetic, because the routers deprioritize the ICMP generation; the definitive signal is the loss at the final hop .


Why mtr requires the per-hop statistics

The snapshot problem.

A single traceroute shows the path at a single moment, and a single ping shows the quality to the destination only. Neither shows whether the loss and the latency are stable over time or whether they vary at the specific hop. The mtr sends the packets continuously and computes the statistics for each hop, which is the mechanism that exposes the intermittent loss and the jitter that the snapshot misses .

The intermediate-hop problem.

The routers in the middle of the path often deprioritize the ICMP responses, because the forwarding is the primary function and the ICMP generation is the secondary one. The result is that an intermediate hop shows the loss while the packets are forwarded perfectly. The mtr output shows the loss at every hop, and the analyst must look at the final hop to determine whether the loss is real. The loss that continues from a hop to the destination is the real loss; the loss that appears at one hop and disappears at the next is cosmetic .

The probe-type problem.

The mtr uses the ICMP echo requests by default, and the ICMP may be blocked by the firewall or the ISP. The -T option sends the TCP SYN packets instead, which are more likely to pass through the firewall, and the -P <port> option specifies the destination port . The -I option uses the ICMP explicitly, and the UDP is the default in some versions. The probe type is the diagnostic variable that the analyst adjusts when the default returns only the asterisks.


a. The interactive display

The interactive display is the default mode. It updates the statistics in real time, and the keyboard shortcuts control the display.

# Start the interactive display
mtr 8.8.8.8

# Disable the DNS resolution
mtr -n 8.8.8.8

# Use the TCP probe on port 80
mtr -T -P 80 google.com

The mtr 8.8.8.8 starts the ncurses display, which shows the hop list with the Loss%, Snt, Last, Avg, Best, Wrst, and StDev columns . The -n option shows the numeric addresses instead of the hostnames, which is faster and avoids the DNS queries. The -T -P 80 sends the TCP SYN packets to the port 80, which is the mechanism that bypasses the ICMP block .

The interactive display has the keyboard shortcuts: h for the help, d for the display mode, r for the restart statistics, o for the field order, and q for the quit . The o shortcut is the mechanism that changes the columns that the display shows, such as the L for the loss, the D for the dropped, the R for the received, and the S for the sent .


b. The report mode

The report mode is the non-interactive form that runs the specified number of cycles and prints the final table.

# Report mode, 10 cycles
mtr -r -c 10 8.8.8.8

# Wide report, no hostname truncation
mtr -r -w -c 10 8.8.8.8

# Report with the numeric output
mtr -r -c 10 -n 8.8.8.8

# Report with the custom fields
mtr -r -c 10 -o "LSD NBAW" 8.8.8.8

The -r option puts the mtr in the report mode, and the -c 10 option runs the 10 cycles before the exit . The -w option prevents the hostname truncation, and the -n option disables the DNS resolution. The -o "LSD NBAW" option specifies the fields and the order: the L for the loss, the S for the sent, the D for the dropped, the N for the newest RTT, the B for the best, the A for the average, and the W for the worst . The report mode is the format for the scripts and the automated tests, because it does not require the interactive terminal .

The report output has the HOST line with the target, and the per-hop rows with the statistics.

HOST: example.com                  Loss%   Snt   Last   Avg  Best  Wrst StDev
  1.|-- 192.168.1.1                 0.0%    10    0.5   0.5   0.4   0.6   0.1
  2.|-- 10.0.0.1                    0.0%    10    2.3   2.3   2.2   2.4   0.1
  3.|-- 93.184.216.34               0.0%    10   12.3  12.3  12.2  12.4   0.1

The Loss% is the percentage of the lost packets, the Snt is the number of the sent packets, the Last is the most recent RTT, the Avg is the average RTT, the Best and Wrst are the minimum and the maximum, and the StDev is the standard deviation .


c. The probe types and the interpretation

The mtr supports the ICMP, the UDP, and the TCP probes. The probe type determines what the tool sends and what the firewall sees.

# ICMP probe (the default)
mtr -I 8.8.8.8

# UDP probe
mtr -u 8.8.8.8

# TCP probe on port 443
mtr -T -P 443 8.8.8.8

The -I option uses the ICMP echo requests, the -u option uses the UDP packets, and the -T -P 443 uses the TCP SYN packets to the port 443 . The TCP probe is the mechanism that passes through the firewalls that block the ICMP and the UDP, which is the common case on the modern networks.

The interpretation of the loss is the most important part. The loss at the final hop is the real loss, and the loss at the intermediate hop is often cosmetic. The StDev is the jitter, and the high value indicates the unstable latency, which degrades the real-time applications such as the voice and the video . The mtr output that shows the loss at the hop 5 but the zero loss at the hop 6 and the later hops is the cosmetic loss, and the output that shows the loss continuing from the hop 5 to the destination is the real loss .


Complete Example Session

# ============================================
# PART 1: INTERACTIVE DISPLAY
# ============================================
mtr 8.8.8.8
# The ncurses display updates in real time

# ============================================
# PART 2: DISABLE THE DNS RESOLUTION
# ============================================
mtr -n 8.8.8.8
# The numeric addresses are shown

# ============================================
# PART 3: REPORT MODE
# ============================================
mtr -r -c 10 8.8.8.8
# The report is printed after the 10 cycles

# ============================================
# PART 4: WIDE REPORT
# ============================================
mtr -r -w -c 10 example.com
# The hostnames are not truncated

# ============================================
# PART 5: TCP PROBE
# ============================================
mtr -T -P 80 google.com
# The TCP SYN packets are sent to the port 80

# ============================================
# PART 6: CUSTOM FIELDS
# ============================================
mtr -r -c 10 -o "LSD NBAW" 8.8.8.8
# The output shows the loss, sent, dropped, newest, best, avg, worst

# ============================================
# PART 7: NO DNS IN THE REPORT
# ============================================
mtr -r -c 10 -n 8.8.8.8
# The report shows the numeric addresses

# ============================================
# PART 8: INTERPRET THE LOSS
# ============================================
mtr -r -c 10 8.8.8.8
# Check the loss at the final hop, not the intermediate hops

# ============================================
# PART 9: CHECK THE JITTER
# ============================================
mtr -r -c 10 8.8.8.8
# The StDev column shows the jitter

# ============================================
# PART 10: CLEAN UP
# ============================================
# Ctrl+C to exit the interactive display

The ten parts demonstrate the mtr surface: the interactive display, the DNS disable, the report mode, the wide report, the TCP probe, the custom fields, the numeric report, the loss interpretation, the jitter check, and the cleanup. The critical interpretation is Part 8: the loss at the final hop is the real loss, and the intermediate hop loss is often cosmetic.


Quick Reference

mtr Modes

ModeCommandPurpose
Interactivemtr <host>Real-time display
Reportmtr -r -c <N> <host>Final table, scripting
Wide reportmtr -r -w -c <N> <host>No hostname truncation
No DNSmtr -n <host>Numeric output
TCP probemtr -T -P <port> <host>Bypass the ICMP block

Report Fields

FieldMeaning
Loss%Percentage of the lost packets
SntNumber of the sent packets
LastMost recent RTT
AvgAverage RTT
Best / WrstMinimum / maximum RTT
StDevStandard deviation (jitter)

Probe Types

TypeFlagUse Case
ICMP-IDefault, when allowed
UDP-uDefault in some versions
TCP-T -P <port>Bypass the ICMP/UDP block

Interpretation

SignalMeaning
Loss at the final hopReal packet loss
Loss at an intermediate hop onlyOften cosmetic
High StDevJitter, unstable latency

Best Practices

โœ… Do This:

# Use the report mode for the scripting
mtr -r -c 10 8.8.8.8                                          # โœ…

# Disable the DNS resolution for the speed
mtr -n 8.8.8.8                                                # โœ…

# Use the TCP probe when the ICMP is blocked
mtr -T -P 80 google.com                                       # โœ…

# Check the loss at the final hop
# The intermediate hop loss is often cosmetic                 # โœ…

# Use the wide report for the full hostnames
mtr -r -w -c 10 example.com                                   # โœ…

# Use the custom fields for the specific analysis
mtr -r -c 10 -o "LSD NBAW" 8.8.8.8                            # โœ…

โŒ Don’t Do This:

# Interpret the intermediate hop loss as the real loss
# The routers deprioritize the ICMP                           # โŒ

# Use the ICMP probe when the firewall blocks it
# The output shows only the asterisks                         # โŒ

# Run the mtr without the -c in the script
mtr -r 8.8.8.8    # Runs forever                              # โŒ

# Ignore the StDev (jitter)
# The high StDev degrades the real-time applications         # โŒ

# Use the mtr for the single-shot check
# Use the ping or the traceroute for the quick check          # โŒ

Common Pitfalls

PitfallWhy It HappensFix
The output shows only the asterisksThe ICMP is blockedUse -T -P <port>
The loss appears at one hop onlyThe router deprioritizes the ICMPCheck the final hop
The report runs foreverNo -cAdd -c <N>
The hostnames are truncatedNo -wAdd -w
The DNS queries slow the testNo -nAdd -n

Real-World Examples

1. Interactive display

mtr 8.8.8.8

2. Report mode

mtr -r -c 10 8.8.8.8

3. Wide report

mtr -r -w -c 10 example.com

4. No DNS

mtr -n 8.8.8.8

5. TCP probe

mtr -T -P 80 google.com

6. Custom fields

mtr -r -c 10 -o "LSD NBAW" 8.8.8.8

7. ICMP probe

mtr -I 8.8.8.8

8. UDP probe

mtr -u 8.8.8.8

9. Check the jitter

mtr -r -c 10 8.8.8.8    # look at the StDev column

10. Check the final hop loss

mtr -r -c 10 8.8.8.8    # look at the last row

Visual

The mtr Display

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  THE PER-HOP STATISTICS                                      โ”‚
โ”‚                                                              โ”‚
โ”‚  Host                    Loss%   Snt   Last   Avg  Best Wrstโ”‚
โ”‚  โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”  โ”‚
โ”‚  โ”‚ 1. 192.168.1.1         0.0%    10    0.5   0.5  0.4  0.6โ”‚  โ”‚
โ”‚  โ”‚ 2. 10.0.0.1            0.0%    10    2.3   2.3  2.2  2.4โ”‚  โ”‚
โ”‚  โ”‚ 3. 93.184.216.34       0.0%    10   12.3  12.3 12.2 12.4โ”‚  โ”‚
โ”‚  โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜  โ”‚
โ”‚                                                              โ”‚
โ”‚  Loss%: the percentage of the lost packets per hop.          โ”‚
โ”‚  StDev: the jitter, the high value means the unstable latencyโ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

The Intermediate Hop Loss

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  THE INTERMEDIATE HOP LOSS IS OFTEN COSMETIC                  โ”‚
โ”‚                                                              โ”‚
โ”‚  Hop 5: Loss 20%    โ† the router deprioritizes the ICMP      โ”‚
โ”‚  Hop 6: Loss 0%     โ† the forwarding is fine                 โ”‚
โ”‚  Hop 7: Loss 0%     โ† the forwarding is fine                 โ”‚
โ”‚                                                              โ”‚
โ”‚  The loss at the final hop is the real loss.                 โ”‚
โ”‚  The loss that continues from a hop to the destination is    โ”‚
โ”‚  the real loss.                                              โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

The Probe Types

โ”Œโ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”
โ”‚  THE PROBE TYPE DETERMINES WHAT THE FIREWALL SEES            โ”‚
โ”‚                                                              โ”‚
โ”‚  ICMP (-I):   the echo requests, often blocked               โ”‚
โ”‚  UDP (-u):    the UDP packets, often blocked                 โ”‚
โ”‚  TCP (-T):    the SYN packets, usually allowed               โ”‚
โ”‚                                                              โ”‚
โ”‚  If the output shows only the asterisks, switch to -T -P 80. โ”‚
โ””โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”˜

Summary

ItemValue
Toolmtr (My TraceRoute)
FunctionPing + traceroute over time
Interactivemtr <host>
Reportmtr -r -c <N> <host>
No DNS-n
TCP probe-T -P <port>
ICMP probe-I
UDP probe-u
Loss signalThe final hop
JitterThe StDev column
Custom fields-o "LSD NBAW"

Key takeaways:

  • mtr combines the ping and the traceroute into a continuous measurement. It discovers the path with the incrementing TTL, and it sends the packets repeatedly to compute the loss and the latency statistics for each hop. The result is a per-hop view of the network quality that the single ping or the single traceroute cannot provide .
  • The report mode is the format for the scripting. The -r -c 10 option runs the 10 cycles and prints the final table, which is the format for the CI pipelines and the automated network tests. The -w option prevents the hostname truncation, and the -n option disables the DNS resolution .
  • The intermediate hop loss is often cosmetic. The routers deprioritize the ICMP generation, so an intermediate hop can show the loss while the packets are forwarded perfectly. The definitive signal is the loss at the final hop, or the loss that continues from a hop to the destination .
  • The TCP probe bypasses the ICMP block. When the default probe returns only the asterisks, the -T -P 80 option sends the TCP SYN packets, which the firewalls usually allow. The probe type is the diagnostic variable that the analyst adjusts .
  • The StDev column is the jitter. The high standard deviation indicates the unstable latency, which degrades the real-time applications such as the voice and the video. The Avg is the average latency, and the Loss% is the packet loss .
  • The custom fields control the output. The -o "LSD NBAW" option specifies the loss, the sent, the dropped, the newest, the best, the average, and the worst. The o keyboard shortcut in the interactive display changes the columns .

Remember: mtr is the tool that shows where on the path the problem is. The interactive display updates in real time, and the report mode produces the table for the scripting. The loss at the final hop is the real loss, and the intermediate hop loss is often cosmetic. The TCP probe bypasses the ICMP block, and the StDev shows the jitter. The result is a tool that answers the question “is the problem at the destination or somewhere in the middle,” which the single ping and the single traceroute cannot answer.


Was this helpful?


Stop using slow, ad-bloated tool sites! ๐Ÿคฎ

๐Ÿ”Ž Search “KandZ Tools” on Google to use many professional utilities for free.

KandZ.me is the ultimate minimalist hub for:
โœ… Finance (Mortgage, Interest, Inflation)
โœ… Tech (Base64, JSON, Dev Suite, IP)
โœ… Health (BMI, BMR, TDEE)
โœ… Productivity (Timer, Workspace, QR)

โšก๏ธ Fast & Private
๐Ÿ”’ No data leaves your device
๐Ÿ’Ž 100% Free

๐Ÿ”— Use it now: https://tools.kandz.me
๐Ÿ”– Bookmark itโ€”youโ€™ll need it later!