Malwarebytes - Cybersecurity for Everyone

Linux traceroute Command Cheat Sheet: Find Network Hops Fast (2026)

byShubham Chaudhary •November 06, 2026

0

Linux traceroute command cheat sheet showing network hops and ICMP, UDP, and TCP probe options in a terminal window

Linux traceroute Command: Complete Cheat Sheet for SOC Analysts and Network Troubleshooting

Last verified: November 6, 2026. Syntax reflects the widely used Linux traceroute package; always confirm with traceroute --help on your own system.

Picture this illustrative scenario. It is 2 a.m., and a SOC analyst gets a ticket: remote staff cannot reach a cloud SaaS application. ping works. DNS resolves. The app times out anyway. The analyst runs a default traceroute and watches it die at hop 7 with a wall of asterisks. Is the provider down? Is a firewall dropping traffic? Or is it just a router ignoring probes? Ten minutes later, a TCP-mode trace to port 443 sails straight through, and the real problem turns out to be somewhere else entirely.

How traceroute Actually Works

Every IP packet carries a hop limit: TTL in IPv4, Hop Limit in IPv6. Each router decrements it by one. When it reaches zero, the router discards the packet and typically sends back an ICMP "Time Exceeded" message. Traceroute exploits this behavior. It sends probes with TTL 1, then 2, then 3, and so on, and records which router answers at each step.

When a probe finally reaches the destination, the reply depends on the probe type. UDP probes normally draw an ICMP "port unreachable" because the target port is closed. ICMP probes draw an echo reply. TCP SYN probes draw a SYN-ACK or RST. That is how traceroute knows the trace is complete.

One important caveat: the path you see is a sample, not a guarantee. Load balancing, asymmetric routing, and per-router ICMP rate limiting all affect what you observe. Treat results as evidence to correlate, not as ground truth.

Reading Output: Asterisks and Status Flags

A typical numeric trace looks like this (documentation IP ranges used for illustration):

traceroute -n 203.0.113.25

 1  192.168.1.1     1.2 ms   1.1 ms   1.0 ms
 2  198.51.100.1    8.4 ms   8.2 ms   8.9 ms
 3  * * *
 4  203.0.113.25   21.7 ms  21.5 ms  22.0 ms

Each line is one TTL value, and each column is one probe. Three asterisks mean no reply arrived before the timeout. That does not automatically mean a failure. Many routers forward traffic fine but deprioritize or suppress ICMP responses. If later hops respond, the silent hop is usually just quiet, not broken.

Traceroute can also annotate hops with status flags, per its documentation:

!H : host unreachable
!N : network unreachable
!P : protocol unreachable
!X : communication administratively prohibited (a strong hint of a filter)
!F : fragmentation needed

An !X at a specific hop is often the fastest way to prove a firewall or ACL is intentionally rejecting traffic.

Essential Flags Cheat Sheet

Flag	Purpose	Example
`-n`	No DNS lookups; faster, cleaner output	`traceroute -n 8.8.8.8`
`-m`	Maximum hops (TTL limit)	`traceroute -m 20 google.com`
`-w`	Seconds to wait per probe response	`traceroute -w 2 google.com`
`-q`	Probes per hop	`traceroute -q 1 google.com`
`-f`	Starting TTL (skip early hops)	`traceroute -f 5 8.8.8.8`
`-4` / `-6`	Force IPv4 or IPv6	`traceroute -6 google.com`
`-s`	Set source IP (must be assigned locally)	`traceroute -s 192.168.1.100 8.8.8.8`
`-i`	Set outgoing interface	`traceroute -i eth0 8.8.8.8`
`-I`	Use ICMP echo probes	`traceroute -I -n 8.8.8.8`
`-T`	Use TCP SYN probes	`traceroute -T -p 443 google.com`
`-U`	Use UDP probes	`traceroute -U -n 8.8.8.8`
`-p`	Destination port (TCP) or starting port (UDP)	`traceroute -T -p 22 192.0.2.10`
`-t`	IPv4 ToS / DS field value	`traceroute -t 16 8.8.8.8`

Two practical notes. First, -w is the wait time per probe, not the total duration of the trace. Total runtime depends on hop count, probes per hop, and timeouts. Second, -t only sets the field in outgoing packets; it does not guarantee any quality-of-service treatment along the path.

A packet length can also be added as an optional final argument, for example traceroute google.com 1400. This behavior is implementation-specific, so check man traceroute before relying on it.

UDP vs ICMP vs TCP: Choosing the Right Probe

This is the section that saves hours. Different networks filter different protocols, so one probe type can fail while another succeeds.

traceroute -n 203.0.113.25
traceroute -I -n 203.0.113.25
traceroute -T -p 443 -n 203.0.113.25

UDP (default): sends UDP packets to high destination ports, with the default range typically starting at 33434. Many corporate firewalls drop these. Use -U to request UDP explicitly.

ICMP (-I): sends ICMP echo requests. This is a good fallback when UDP is filtered but ICMP is permitted. Depending on your distribution, ICMP and TCP modes may require elevated privileges, so prefix with sudo if you see permission errors.

TCP SYN (-T): sends SYN packets to a port you choose. Because the traffic resembles a real connection to a real service, it is the most likely to pass through firewalls that permit web traffic. Common test ports include 22 (SSH), 53 (DNS over TCP), 80 (HTTP), and 443 (HTTPS).

If UDP stalls and TCP 443 completes, you have learned something valuable: the application path is probably reachable, and the earlier asterisks were filtering behavior, not an outage.

Network Path Troubleshooting Workflow

Before blaming a provider, verify your own side. This sequence works well as a repeatable checklist:

# What route does the kernel choose?
ip route get 8.8.8.8

# Interface addresses
ip -br addr

# Interface packet statistics (look for errors and drops)
ip -s link

# Neighbor (ARP/NDP) table
ip neigh

# DNS resolution through the system resolver
getent hosts google.com

# Basic connectivity
ping -c 4 8.8.8.8

# Then trace, numeric to avoid DNS delays
traceroute -n 8.8.8.8
traceroute -n 192.168.1.1

Tracing to the local gateway first tells you whether the problem starts inside your own network. If hop 1 is slow or silent, no amount of upstream analysis will help. The ip route get output also confirms which interface and source address traffic will actually use, which matters before you reach for -i or -s on a multi-homed server.

SOC and DFIR Evidence Capture

During an investigation, "I ran traceroute and it looked odd" is not evidence. A timestamped, multi-protocol capture is. This block records the route decision plus all three probe types in one file:

{
date -Is
echo "===== ROUTE TO DESTINATION ====="
ip route get 8.8.8.8
echo "===== UDP TRACEROUTE ====="
traceroute -n -q 2 -w 2 8.8.8.8
echo "===== ICMP TRACEROUTE ====="
traceroute -I -n -q 2 -w 2 8.8.8.8
echo "===== TCP TRACEROUTE ====="
traceroute -T -p 443 -n -q 2 -w 2 8.8.8.8
} | tee "traceroute-investigation-$(date +%Y%m%d-%H%M%S).txt"

The command writes to the screen and to a uniquely named file at the same time. Expect three trace outputs, each preceded by its label. Run it from the affected host, and ideally from a known-good host for comparison. If you want to see exactly what your probes look like on the wire, run a capture in a second terminal:

sudo tcpdump -ni any 'icmp or udp'
sudo tcpdump -ni any 'tcp port 443'

Seeing the TTL-limited probes leave and the Time Exceeded replies return is the quickest way to confirm whether a middlebox is dropping traffic before or after your host.

Automation and Scripting

# Save a trace to a file
traceroute -n google.com > traceroute.txt

# Append a timestamped trace to a running history
{
date -Is
traceroute -n google.com
} >> route-history.txt

# Trace several destinations
for host in 8.8.8.8 1.1.1.1 google.com; do
  echo "Tracing $host"
  traceroute -n -m 20 -q 2 "$host"
done

A route history file becomes powerful over time. When users complain about intermittent slowness, comparing today's path against last week's often reveals a provider route change within seconds.

Warning about exit codes: a successful exit status only means the command ran. It does not mean every hop answered. Never build monitoring that treats exit code 0 as "network healthy." Parse the actual output for timeouts and for whether the final destination responded.

Alternatives: tracepath and mtr

tracepath -n 8.8.8.8
mtr -n google.com
mtr -rw 8.8.8.8
mtr -r -c 10 8.8.8.8
busybox traceroute google.com

tracepath works without root and also reports path MTU, which is handy for diagnosing fragmentation issues. mtr combines traceroute and ping into a continuous view: -r is report mode, -w is wide output, -n is numeric, and -c sets the number of cycles. For intermittent packet loss, mtr with a report of 10 to 100 cycles gives you far better statistics than a single traceroute pass. BusyBox's traceroute is a stripped-down variant common on embedded and minimal systems, so expect fewer options.

Detection and Defense for Network Detection and Response Teams

Traceroute is a legitimate admin tool, but it is also a classic reconnaissance step. Attackers who gain a foothold sometimes map internal topology to find gateways and segmentation boundaries. Defenders should know what it looks like.

Telltale pattern: a single source sending packets to the same destination with steadily increasing TTL values, often to sequential high UDP ports or repeated ICMP echoes.
Firewall logs: bursts of denied UDP to ports in the 33434 range, or a flood of ICMP Time Exceeded messages, from one internal host are worth a look when the host has no business doing network diagnostics.
NDR and IDS: network detection and response platforms and common IDS rule sets can flag TTL-sweep behavior. Tune them so that known admin jump hosts and monitoring servers are baselined and do not drown analysts in noise.
Context matters: traceroute from a network engineer's workstation during an outage ticket is expected. The same activity from a database server at 3 a.m. is a lead.

Expert Tips

Always use -n during incidents. Reverse DNS lookups add delay and can even create extra DNS noise you will have to explain later.
Lower -q and -w (for example -q 1 -w 1) for a fast first look, then raise them for a careful second pass.
Compare protocols, not just hosts. Disagreement between UDP, ICMP, and TCP results is itself a finding.
Use -f to skip hops you already trust and focus on the segment you suspect.
Run the trace from both ends when you can. Return paths often differ from forward paths.
Record the tool version with traceroute --version and command -v traceroute. Implementations differ, and your notes should say which one produced the evidence.

Installing the Tools

# Debian / Ubuntu
sudo apt update
sudo apt install traceroute
sudo apt install iputils-tracepath
sudo apt install mtr-tiny

# Fedora / RHEL / Rocky / AlmaLinux
sudo dnf install traceroute
sudo dnf install mtr

# Arch Linux
sudo pacman -S traceroute
sudo pacman -S mtr

Package names and availability vary by distribution and release, so check your package manager if an install fails.

Linux Ping Command Cheat Sheet (2026): Complete Guide
Linux ifconfig Cheat Sheet: Commands, MTU, MAC & PROMISC
Linux ip Command Cheat Sheet: Spot Rogue Routes & ARP Spoofing
Linux Networking Commands Cheat Sheet: ip, ss, nmap (2026)
SBI CyRIS Cybersecurity Centre of Excellence: Full Breakdown
Linux pstree Command Cheat Sheet: Spot Suspicious Processes Fast
Linux pgrep Command Cheat Sheet: Find Suspicious Processes Fast
Linux pmap Command Cheat Sheet: 40 Examples for Memory Analysis

FAQ

Why does traceroute show asterisks at some hops?

The router did not reply within the timeout. Common reasons include ICMP rate limiting, a firewall dropping the probe type, or a device configured not to answer. If later hops respond, forwarding is usually fine.

What is the difference between traceroute and ping?

Ping tests whether a destination responds and how fast. Traceroute shows each router along the path, which helps you locate where delay or filtering occurs.

Which probe type should I use first?

Start with the default, then try ICMP (-I) if UDP is filtered. For application-level reachability, use TCP (-T -p 443 for HTTPS).

Does a high latency at one hop mean there is a problem?

Not necessarily. Routers often handle ICMP responses at low priority, so a slow reply at one hop followed by normal latency afterward is typically harmless. Sustained latency that continues through later hops is the real warning sign.

Is it legal to run traceroute?

Traceroute is a standard diagnostic tool, but you should only test networks you are authorized to assess. Policies and laws vary, so follow your organization's rules.

When should I use mtr instead?

Use mtr for intermittent loss or jitter. It sends probes continuously and reports statistics per hop, which a single traceroute pass cannot do.

Can traceroute help during an incident investigation?

Yes, as supporting evidence. Timestamped traces across UDP, ICMP, and TCP show path behavior and filtering, and they pair well with packet captures and firewall logs.

Conclusion

Traceroute rewards the analyst who understands what it is really measuring: TTL expiry responses, not guaranteed truth. Learn the flags, compare UDP, ICMP, and TCP results, capture output with timestamps, and treat silent hops with healthy skepticism. Do that, and a vague "the network is slow" ticket becomes a specific, defensible finding. Bookmark the commands above, adapt them to your environment, and keep your testing within authorized scope.

Analysis based on SOC monitoring experience and review of public Linux networking documentation.