LFCS 104 🐧 Connectivity Testing — ping, traceroute, mtr - KandZ

⏱️ Estimated read: 10 min | |

Network troubleshooting begins with a simple question: can machine A reach machine B? The tools ping, traceroute, and mtr answer this question at increasingly deep levels. ping tests whether a host is reachable and measures round-trip time. traceroute reveals the path packets take through the network, hop by hop. mtr combines both into a continuous, real-time diagnostic display. For the LFCS exam, knowing how to invoke each tool, interpret its output, and understand the limitations of ICMP-based testing is essential.

Key point: All three tools rely on ICMP (Internet Control Message Protocol) or UDP/TCP by default. Firewalls frequently block these protocols. A failed ping does not prove a host is offline—it only proves that ICMP echo replies are not being received.

Why connectivity testing tools exist

The reachability problem. A network failure can occur at the physical layer (cable unplugged), the link layer (switch misconfigured), the network layer (routing failure), or the transport layer (port closed). ping tests the first three in a single command. It sends an ICMP Echo Request and waits for an Echo Reply. If the reply arrives, the network path is functional end-to-end. If it does not, the failure is somewhere between the two hosts.

The path problem. When ping succeeds but performance is poor, the question becomes “where is the delay?” traceroute sends packets with incrementally increasing Time-To-Live (TTL) values. The first packet has TTL 1 and expires at the first router, which returns an ICMP Time Exceeded message. The second packet has TTL 2 and expires at the second router, and so on. The result is a list of every router between the sender and the destination.

The intermittent problem. A path might be functional most of the time but fail intermittently. traceroute provides a single snapshot. mtr (My TraceRoute) runs continuously, combining ping and traceroute into a live display. Each hop shows packet loss percentage and latency statistics, updated every second. This makes intermittent packet loss visible in real time.

The firewall problem. Many networks block ICMP for security reasons. A host that drops ICMP Echo Requests will appear unreachable to ping even if it is fully operational. traceroute on Linux defaults to UDP packets for the same reason—some firewalls allow UDP while blocking ICMP. The tools are diagnostic aids, not proof of reachability.

The trade-off. ping is fast and simple but provides no path information. traceroute provides path information but is a point-in-time measurement. mtr provides continuous data but requires an interactive terminal. Each tool answers a different question.

a. `ping`: testing reachability

ping sends ICMP Echo Requests to a target and waits for replies. The default behavior on Linux is to send one request per second indefinitely until interrupted. The -c flag limits the count, which is essential for scripting and for exam environments where you do not want the command to block forever.

# Send 4 pings and stop
ping -c 4 8.8.8.8

# Ping a hostname (tests DNS and connectivity)
ping -c 4 google.com

# Flood ping (requires root, for latency testing)
sudo ping -f 192.168.1.1

# Set interval between pings (0.2 seconds)
ping -i 0.2 -c 5 192.168.1.1

The output shows the size of the packet, the sequence number, the TTL of the reply, and the round-trip time. At the end, it prints a summary with the minimum, average, maximum, and standard deviation of the round-trip times, plus the packet loss percentage.

If ping reports “Destination Host Unreachable” or “Request timeout,” the cause could be a missing route, a firewall blocking ICMP, or a genuinely offline host. If it reports “Name or service not known,” the failure is in DNS resolution, not connectivity.

b. `traceroute`: discovering the path

traceroute maps the route from the local machine to a destination. On Linux, it defaults to sending UDP packets to high-numbered ports (starting at 33434) with increasing TTL values. When a packet expires at a router, the router returns an ICMP Time Exceeded message, and traceroute records the router’s IP address and the round-trip time for that hop.

# Default UDP traceroute
traceroute 8.8.8.8

# Use ICMP instead of UDP (requires root)
sudo traceroute -I 8.8.8.8

# Use TCP SYN packets to a specific port (bypasses UDP blocks)
sudo traceroute -T -p 80 google.com

# Disable DNS resolution (faster output)
traceroute -n 8.8.8.8

The output lists each hop with its IP address and three round-trip times (one for each probe packet sent per hop). Asterisks (*) indicate that no response was received within the timeout—this usually means a router is configured not to respond to ICMP or UDP probes. The -n flag disables DNS lookups, which makes the output faster and avoids delays from unreachable reverse DNS zones.

The choice of probe type matters. If UDP traceroute returns only asterisks after the first few hops, a firewall may be blocking UDP. -I switches to ICMP, and -T switches to TCP. One of the three usually reaches the destination.

c. `mtr`: continuous path analysis

mtr (My TraceRoute) combines ping and traceroute into a continuously updating display. It sends packets to each hop at regular intervals and displays packet loss and latency statistics for each hop in real time.

# Interactive display
mtr 8.8.8.8

# Report mode (10 cycles, then exit)
mtr -r -c 10 8.8.8.8

# No DNS resolution (faster)
mtr -n 8.8.8.8

# TCP mode (like traceroute -T)
mtr -T -P 80 google.com

The interactive display has two columns: “Loss%” and “StDev” (standard deviation). High loss at a particular hop indicates a problem at that hop or the link leading to it. High standard deviation indicates jitter—the latency is unstable, which degrades real-time applications like voice and video.

The -r (report) flag makes mtr non-interactive. It runs for the specified number of cycles (-c 10) and then prints a final report. This is the format used in CI pipelines and automated network tests, where interactive terminals are not available.

A key caveat with mtr output: packet loss at an intermediate hop does not necessarily mean the destination is unreachable. Some routers prioritize forwarding over generating ICMP responses, so they appear lossy while forwarding traffic perfectly. The definitive signal is loss at the final hop (the destination).

Complete Example Session

# ============================================
# PART 1: BASIC PING
# ============================================

ping -c 4 8.8.8.8
# 4 packets transmitted, 4 received, 0% packet loss
# rtt min/avg/max/mdev = 12.1/12.8/13.4/0.5 ms

# ============================================
# PART 2: PING A HOSTNAME
# ============================================

ping -c 4 google.com
# Resolves to 142.250.190.14 and replies.
# Tests both DNS and connectivity.

# ============================================
# PART 3: PING FAILURE
# ============================================

ping -c 2 10.99.99.99
# 2 packets transmitted, 0 received, 100% packet loss
# Host may be offline or ICMP blocked.

# ============================================
# PART 4: TRACEROUTE (UDP)
# ============================================

traceroute -n 8.8.8.8
# 1  192.168.1.1  1.234 ms  1.456 ms  1.789 ms
# 2  10.0.0.1     5.123 ms  5.456 ms  5.789 ms
# 3  * * *
# 4  * * *
# ...
# 12 8.8.8.8      12.345 ms 12.678 ms 12.901 ms
# Hops 3-11 do not respond to UDP probes.

# ============================================
# PART 5: TRACEROUTE (ICMP)
# ============================================

sudo traceroute -I -n 8.8.8.8
# Hops that did not respond to UDP respond to ICMP.

# ============================================
# PART 6: TRACEROUTE (TCP)
# ============================================

sudo traceroute -T -p 80 -n google.com
# Uses TCP SYN to port 80.
# Bypasses firewalls that block UDP and ICMP.

# ============================================
# PART 7: MTR INTERACTIVE
# ============================================

mtr 8.8.8.8
# Live display of loss and latency per hop.
# Ctrl+C to exit.

# ============================================
# PART 8: MTR REPORT MODE
# ============================================

mtr -r -c 10 -n 8.8.8.8
# 10 cycles, then a final report.
# Suitable for scripting.

# ============================================
# PART 9: INTERPRET LOSS
# ============================================

# Loss at hop 5 but not at hop 6 or later
# → hop 5 deprioritizes ICMP; not a real problem.
# Loss that continues from hop 5 to the destination
# → real packet loss on the path.

The nine parts trace the three tools: basic ping, hostname ping, ping failure, UDP traceroute, ICMP traceroute, TCP traceroute, interactive mtr, report-mode mtr, and interpreting loss at intermediate hops.

Quick Reference

ping Commands

Command	Purpose
`ping <host>`	Continuous ping
`ping -c 4 <host>`	Send 4 packets
`ping -i 0.2 -c 5 <host>`	Interval between packets
`ping -f <host>`	Flood ping (root)

traceroute Commands

Command	Purpose
`traceroute <host>`	Default (UDP)
`traceroute -I <host>`	ICMP probe (root)
`traceroute -T -p 80 <host>`	TCP SYN to port 80
`traceroute -n <host>`	Disable DNS resolution

mtr Commands

Command	Purpose
`mtr <host>`	Interactive display
`mtr -r -c 10 <host>`	Report mode, 10 cycles
`mtr -n <host>`	No DNS resolution
`mtr -T -P 80 <host>`	TCP mode

Probe Types

Type	Flag	Bypasses
UDP	(default traceroute)	Nothing
ICMP	`-I`	UDP blocks
TCP	`-T`	UDP and ICMP blocks

Best Practices

✅ Do This:

ping -c 4 8.8.8.8
<!-- Always limit the count in non-interactive shells --> # ✅

sudo traceroute -T -p 80 google.com
<!-- Use TCP when ICMP is blocked -->                  # ✅

mtr -r -c 10 -n 8.8.8.8
<!-- Report mode for reproducible output -->          # ✅

❌ Don’t Do This:

# Assume ping failure means host is offline
<!-- ICMP may be blocked by firewall -->              # ❌

# Interpret loss at intermediate hops as failure
<!-- Routers deprioritize ICMP generation -->         # ❌

# Run traceroute without -n in scripts
<!-- DNS lookups slow execution and fail on dead zones --> # ❌

Common Pitfalls

Pitfall	Why It Happens	Fix
Ping fails but host is up	ICMP blocked	Test with `nc -z` or TCP traceroute
Traceroute shows only asterisks	UDP blocked	Use `-I` (ICMP) or `-T` (TCP)
mtr shows loss at intermediate hop	Router deprioritizes ICMP	Check loss at final hop; intermediate loss is often cosmetic
Ping waits indefinitely	No `-c` flag	Add `-c <count>`
`Name or service not known`	DNS resolution failed	Fix DNS or use IP address

Real-World Examples

1. Basic Ping

ping -c 4 8.8.8.8

2. Ping Hostname

ping -c 4 google.com

3. Ping with Interval

ping -i 0.2 -c 5 192.168.1.1

4. Default Traceroute

traceroute 8.8.8.8

5. ICMP Traceroute

sudo traceroute -I 8.8.8.8

6. TCP Traceroute

sudo traceroute -T -p 80 google.com

7. Traceroute Without DNS

traceroute -n 8.8.8.8

8. Interactive mtr

mtr 8.8.8.8

9. mtr Report

mtr -r -c 10 8.8.8.8

10. mtr TCP Mode

mtr -T -P 80 google.com

Visual

Ping Flow

┌──────────────────────────────────────────────┐
│  Host A: ping 8.8.8.8                        │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  ICMP Echo Request sent                      │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Routers forward the packet                  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Host B receives and replies with ICMP Echo  │
└──────────────────┬───────────────────────────┘
                   │
                   ▼
┌──────────────────────────────────────────────┐
│  Host A measures round-trip time             │
└──────────────────────────────────────────────┘

Traceroute TTL Mechanism

TTL=1  →  Router 1 (returns Time Exceeded)
TTL=2  →  Router 2 (returns Time Exceeded)
TTL=3  →  Router 3 (returns Time Exceeded)
...
TTL=N  →  Destination (returns Echo Reply or Port Unreachable)

Each TTL value reveals one hop in the path.

Summary

Item	Value
Reachability test	`ping`
Path discovery	`traceroute`
Continuous path analysis	`mtr`
Default traceroute probe	UDP (Linux)
ICMP probe flag	`-I` (root)
TCP probe flag	`-T`
No DNS flag	`-n`
mtr report mode	`-r -c <N>`

Key takeaways:

ping tests reachability, not correctness. A reply confirms the path and ICMP handling. Silence means the host is offline or ICMP is blocked. The distinction requires another tool.
traceroute reveals the path by exploiting TTL. Each router that receives an expired packet returns an error, and the error identifies the router. The probe type matters: UDP, ICMP, and TCP reach different layers and bypass different firewalls.
mtr is ping plus traceroute over time. It exposes intermittent loss and jitter that a single traceroute snapshot misses.
Intermediate hop loss is often cosmetic. Routers deprioritize ICMP generation. The signal that matters is loss at the destination.
The probe type is a diagnostic variable. If UDP traceroute returns only asterisks, switch to ICMP (-I) or TCP (-T). One of the three will usually reach the destination.

Remember: Connectivity testing is not a single command. It is a progression: ping for reachability, traceroute for path, mtr for continuous analysis. Each tool has a probe type, and each probe type can be blocked by a firewall. When one fails, try the next. The destination’s response is the only definitive 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!