ping, traceroute & mtr
These three commands are the first thing to reach for whenever something is slow or unreachable. Each answers a slightly different question, and knowing which one to run first (and when to escalate to the next) is most of the skill.
ping: is it up, and how far away
ping sends ICMP Echo Request packets and times the Echo Reply for
each one. It answers exactly two questions: is the host reachable, and what is
the round-trip time (RTT)? See ICMP, Ping & Traceroute
for how the Echo Request/Reply exchange works at the protocol level.
The three numbers that matter:
- loss % - any non-zero loss on a wired path is worth investigating; a little loss on Wi-Fi is normal.
- avg RTT - the baseline latency to that host; compare against a known-good baseline, not an absolute number.
- jitter (the spread between min and max, or stddev) - a stable RTT with
one outlier (like
icmp_seq=2above) suggests a transient event, not a structural problem.
Windows uses ping -n <count> instead of -c, and reports Reply from instead
of the BSD-style 64 bytes from. The concept is identical.
Some hosts and middleboxes rate-limit or outright drop ICMP as a matter of policy. A host that does not respond to ping is not necessarily down - it may simply be configured to ignore Echo Requests while still serving TCP traffic fine. Never conclude "the service is down" from ping alone.
traceroute: which hop
ping tells you whether you can reach the destination, not where a
problem is along the way. traceroute (tracert on Windows) answers that by
exploiting the IP TTL field, sending probes with increasing TTL so each router
along the path expires exactly one probe and reports itself back - the
mechanism is covered in detail in
ICMP, Ping & Traceroute; this page is
about reading the output in practice.
Each row is one hop, with three probes and three RTTs. * * * means that hop
did not reply within the timeout - usually a router configured not to send
ICMP Time Exceeded, not a broken link, especially when later hops still
respond.
A jump in latency at a given hop does not automatically mean that router is slow. It might just be the first hop willing to send back an ICMP reply with accurate timing, after several silent hops in between. Treat a single hop's RTT with suspicion; treat a sustained increase from that hop onward as real.
mtr: ping and traceroute, continuously
traceroute is a snapshot: one pass, one moment in time. If loss is
intermittent, a single traceroute can easily miss it. mtr (My Traceroute)
solves this by combining both tools: it repeatedly pings every hop along the
path and keeps a running loss and latency statistic per hop, live, instead of
a single sample.
This is the key advantage over running ping and traceroute separately:
loss and latency are attributed per hop, over many samples, so you can see
that hop 4 is dropping roughly a quarter of probes and adding wild jitter,
while every hop after it looks fine. Since traffic to hop 6 still passes
through hop 4, the loss and latency showing up at hop 4 is the real story -
hops 5 and 6 recovering does not mean the problem there is harmless, it means
those routers are absorbing retransmitted/re-routed traffic downstream of a
lossy link.
Loss reported at an intermediate hop but not at the final destination is often the router itself deprioritizing ICMP replies to save CPU (common on core routers) - not real packet loss for your traffic. Loss that appears at a hop and every hop after it is far more likely to be a genuine problem at that hop.
mtr -rw above ran 50 probes per hop over roughly 50 seconds by default (one
per second). More samples make an intermittent problem far more visible than
a traceroute's single pass ever could.