Three Tools, Three Questions
ping answers "can I reach it and how fast?" traceroute answers "what path do my packets take?" MTR answers "where in the path is the problem?" Understanding which question you are asking determines which tool to reach for.
Using the wrong tool wastes time. ping cannot tell you where latency happens. traceroute shows you a single snapshot that can be misleading. MTR combines both but generates a lot of output you need to know how to read.
ping: The Reachability Check
ping sends an ICMP Echo Request and waits for an Echo Reply. It measures round-trip time, packet loss, and jitter. That is all it does.
Use ping when:
- You need to confirm basic connectivity to a host
- You want to measure end-to-end latency and jitter
- You are monitoring link quality over time
- You need a quick yes/no answer
ping -c 10 -i 0.2 8.8.8.8
# Output: min/avg/max/mdev = 11.2/12.5/14.1/0.8 ms, 0% lossping is the first tool to run. If it fails, nothing else matters — you have a fundamental reachability problem. If it succeeds with high latency or loss, you move to MTR to find where.
traceroute: The Path Mapper
traceroute sends probes with increasing TTL values. The first probe has TTL=1 (dies at the first router), the second has TTL=2, and so on. Each router sends back an ICMP Time Exceeded message, revealing its IP address.
traceroute 8.8.8.8
# 1 192.168.1.1 2.1ms
# 2 10.0.0.1 8.3ms
# 3 72.14.212.1 12.7ms
# 4 8.8.8.8 11.9msThe default traceroute on Linux sends UDP probes to high ports (33434+). You can switch to ICMP with -I or TCP with -T. TCP traceroute is useful when ICMP is blocked by firewalls — it uses TCP SYN packets that look like normal connection attempts.
The traceroute trap: traceroute shows you three latency samples per hop. Three. If you have intermittent packet loss that happens every 10th packet, traceroute will probably miss it. This is the biggest reason traceroute results are misleading. You see clean latency and think the path is fine, when in reality 10% of packets are dropping on hop 4.
MTR: The Continuous Path Analyzer
MTR (My Traceroute, originally "Matt's TraceRoute") combines ping and traceroute into a continuous measurement. Instead of three probes per hop, MTR sends packets continuously — typically one per second — and accumulates statistics.
mtr -r -c 100 8.8.8.8The output shows every hop with: loss%, sent packets, last latency, average latency, best, worst, and standard deviation. After 100 cycles, you have a statistically meaningful picture of the path.
Reading MTR output correctly:
- Loss on one hop, not on subsequent hops: The router is deprioritizing ICMP replies. Not a real problem.
- Loss on one hop AND all subsequent hops: Real packet loss at that hop.
- High latency on hop N but not N+1: Router N is slow to generate ICMP replies but fast to forward packets. Ignore it.
- High latency on hop N AND N+1 through destination: Real congestion starting at hop N.
- High jitter (standard deviation): Unstable link — worse than consistently high latency.
When to Use Each
| Situation | Tool | Why |
|---|---|---|
| "Is the server down?" | ping | Fast yes/no. One command. |
| "What route does my traffic take?" | traceroute | Shows the path. Single snapshot. |
| "Where is the packet loss?" | MTR -c 100 | Accumulates enough data to find intermittent loss. |
| "Why is latency spiking?" | MTR continuous | Watch in real-time (no -r flag) to see which hop spikes. |
| "Is my ISP routing me badly?" | MTR -c 200 | 200 samples gives you ammunition for your ISP ticket. |
| "Firewall blocking ICMP?" | traceroute -T | TCP traceroute bypasses ICMP restrictions. |
Real Scenario: The Case of the Missing Packets
A game server hosting company received complaints from players in Brazil about random disconnections. The US-based ops team ran ping and traceroute: both clean. ping -c 100 showed 0% loss. traceroute showed 12 hops, all under 50ms.
The Brazilian network engineer ran MTR instead:
mtr -r -c 500 game-server-us.example.comHop 8 — a peering exchange in Miami — showed 3% loss that propagated to every subsequent hop. Since it was a peering link between two carriers, neither ISP took responsibility. The fix was changing the game server's BGP announcements to prefer a different peering path through Dallas, adding 15ms of latency but eliminating the packet loss entirely.
ping and traceroute both missed it because 3% intermittent loss over 100 samples is not statistically guaranteed to appear. MTR with enough samples caught it.
Quick Command Reference
# Quick reachability
ping -c 4 TARGET
# Path + basic latency
traceroute TARGET
# TCP traceroute (ICMP blocked)
traceroute -T -p 443 TARGET
# Statistical path analysis (report mode)
mtr -r -c 100 TARGET
# Real-time MTR (interactive curses UI)
mtr TARGET
# MTR with specific packet size
mtr -r -c 100 -s 1400 TARGET
# Combine with OpsCheck for external perspective
# Use OpsCheck Ping Test to compare your MTR results
# with measurements from multiple geographic locationsping for speed. traceroute for path. MTR for truth. Run all three, but trust MTR when they disagree.