traceroute

Path tracing — hop-by-hop latency, ICMP/UDP/TCP modes, and asymmetric route detection.

Basic Path Tracing

Standard traceroute — sends UDP probes with incrementing TTL, shows each hop

traceroute 8.8.8.8

No DNS resolution — faster, avoids delays from reverse lookups on every hop

traceroute -n 8.8.8.8

Set max hops — default is 30, lower it to stop early on known short paths

traceroute -n -m 15 10.50.1.1

Send more probes per hop — default is 3, increase to 5 for better latency sampling

traceroute -n -q 5 8.8.8.8

Set wait timeout — reduce from 5s default when you know hops should respond fast

traceroute -n -w 2 8.8.8.8

Protocol Variations

TCP traceroute — uses TCP SYN instead of UDP, passes through firewalls that block UDP/ICMP

sudo traceroute -T -p 443 10.50.1.20

ICMP traceroute — uses ICMP Echo like ping, most basic method

sudo traceroute -I 8.8.8.8

Specify source interface — for multi-homed hosts, force traffic out a specific NIC

traceroute -n -i eth0 8.8.8.8

Set initial TTL — skip known hops at the beginning of the path

traceroute -n -f 5 8.8.8.8

tracepath (No Root Required)

tracepath — similar to traceroute but discovers MTU along the path, no root needed

tracepath -n 8.8.8.8

tracepath with explicit port — test path to a specific service

tracepath -n -p 443 10.50.1.20

mtr (My Traceroute)

Interactive mtr — continuous traceroute with live-updating statistics per hop

mtr 8.8.8.8

Non-interactive report — run 100 cycles and print a summary, good for scripts and tickets

mtr -n --report -c 100 8.8.8.8

Wide report with no DNS — shows full IP addresses, no truncation

mtr -nw --report -c 100 8.8.8.8

TCP mode — bypasses ICMP-blocking firewalls, tests the actual forwarding path for TCP

sudo mtr -n --tcp --port 443 10.50.1.20

UDP mode on a specific port — test the same path RADIUS or DNS traffic takes

sudo mtr -n --udp --port 1812 10.50.1.20

Set packet size — test for MTU issues, 1500 bytes should pass unfragmented on standard Ethernet

mtr -n --report -s 1500 8.8.8.8

JSON output — machine-parseable for monitoring systems

mtr -n --report --json -c 50 8.8.8.8

Interpreting Results

Asterisks (* * *) — hop does not respond to probes but may still forward traffic, not necessarily a problem

# Hop 5:  * * *
# This usually means the router has ICMP rate-limiting or TTL-expired responses disabled.
# If subsequent hops respond normally, the path is fine.

Latency spike at one hop but recovery afterward — ICMP deprioritization, not real congestion

# Hop 4: 50ms (spike)
# Hop 5: 10ms (normal)
# The router at hop 4 deprioritizes ICMP replies. The forwarding path is not slow.

Latency spike that persists through all subsequent hops — real congestion or saturation at that hop

# Hop 4: 50ms
# Hop 5: 55ms
# Hop 6: 52ms
# Sustained increase from hop 4 onward = real problem at or near hop 4.

High packet loss at a single hop but not at the destination — ICMP rate limiting, not a problem

# Hop 3: 40% loss
# Hop 7 (destination): 0% loss
# The intermediate router drops ICMP replies under load. Forwarding is fine.

Asymmetric routing — forward and return paths differ, can cause confusing traceroute results

# Compare: traceroute from A→B and B→A
# If paths differ, latency measurements at individual hops are unreliable.
# Only the destination hop latency is meaningful in asymmetric networks.