Cisco IOS traceroute Command: Path Discovery and Troubleshooting

Learn how Cisco IOS traceroute discovers Layer 3 hops, how to read response symbols, and how to troubleshoot failed or filtered paths.

The Cisco IOS traceroute command discovers the Layer 3 devices traversed between a router and a destination. It is useful for validating the forwarding path and locating the likely boundary of a connectivity problem.

Traceroute is not the same as ping. A ping primarily tests end-to-end reachability. Traceroute displays the intermediate hops that respond while the probe travels toward the destination.

How Cisco IOS traceroute works

A probe is an individual test packet sent by traceroute. Traceroute sends probes with increasing IPv4 Time To Live (TTL) values. TTL is an IPv4 field that routers decrement when forwarding a packet.

The first probes use TTL 1. The first router decrements the value to zero and normally returns an ICMP Time Exceeded message.
The next probes use TTL 2. The first router forwards them, and the second router expires the TTL and returns the response.
This process continues with larger TTL values, exposing successive Layer 3 hops.
When a probe reaches the destination network stack, the destination may return a destination-related response. The exact response depends on the probe type and the result.

The router displays the address from which it receives the response. That address is an interface selected for return traffic, so it might not be the exact forwarding interface you expected to see in a diagram.

The time shown for each probe is its round-trip time (RTT): the elapsed time for the probe to reach the responding device and for the response to return, normally displayed in milliseconds.

Basic IOS command usage

Run the command from privileged EXEC mode, shown by a prompt ending in #:

R1# traceroute <destination-ip-address>

For the example destination, trace from R1 to R4's FastEthernet0/0 address:

R1# traceroute 172.16.0.2

IOS may ask for additional traceroute parameters, depending on the platform and release. Accept the defaults for a basic test, or provide values when you need a particular source address, probe count, or timeout.

Output is organized by hop number. Each line normally contains the responding address followed by one RTT value for each probe. For example:

R1# traceroute 172.16.0.2
Type escape sequence to abort.
Tracing the route to 172.16.0.2
  1  10.0.12.2  4 msec  4 msec  8 msec
  2  192.168.5.2  12 msec  12 msec  16 msec
  3  172.16.0.2  20 msec  20 msec  24 msec

In this example, hop 1 is R2, hop 2 is R3, and hop 3 is the final destination on R4. The three timing values represent separate probes for that hop.

Reading a successful four-router trace

Assume the normal routed topology is R1 → R2 → R3 → R4. R1 sends traffic through R2 and R3 before reaching R4's FastEthernet0/0 address, 172.16.0.2.

R1# traceroute 172.16.0.2
Type escape sequence to abort.
Tracing the route to 172.16.0.2
  1  10.0.12.2       3 msec   4 msec   3 msec
  2  192.168.5.2    11 msec  10 msec  12 msec
  3  172.16.0.2     18 msec  19 msec  18 msec

Hop 1: R2 responds with the interface address it selected for the return traffic.
Hop 2: R3 responds, identified here as 192.168.5.2.
Hop 3: R4 or its destination interface responds with 172.16.0.2.

Because this is a four-router path, three routed hops appear before or at the destination response: R2, R3, and R4. The sequence reflects the forwarding path currently selected by R1's routing table, not necessarily every physical device or interface in the topology.

Reading failed or incomplete traces

A missing response is commonly displayed as an asterisk (*) or a timeout-related indication. The probe may have been discarded, its response may have been filtered, or the response may not have returned before the timeout.

A useful rule of thumb is to investigate the last confirmed responding router and the next hop that should have appeared. This identifies a troubleshooting boundary; it does not prove that the last router is the failed device.

Example: R3 is unavailable

Suppose the normal R1-to-R4 path is R1 → R2 → R3 → R4, and R3's relevant address is 192.168.5.2. If R3 is truly unavailable, it should not respond at hop 2:

R1# traceroute 172.16.0.2
Type escape sequence to abort.
Tracing the route to 172.16.0.2
  1  10.0.12.2       4 msec   4 msec   8 msec
  2  *  *  *
  3  *  *  *
  4  *  *  *

Here, R2 is the last confirmed hop and the expected next hop is R3 at 192.168.5.2. Check R3, the link from R2 to R3, and the route from R2 toward the destination.

Example: R3 responds with a host-unreachable message

A different condition occurs when R3 is reachable but cannot forward traffic to R4:

R1# traceroute 172.16.0.2
Type escape sequence to abort.
Tracing the route to 172.16.0.2
  1  10.0.12.2       4 msec   4 msec   8 msec
  2  192.168.5.2    12 msec  12 msec  16 msec
  3  192.168.5.2 !H  12 msec  !H  16 msec  !H

!H means that a device reported the destination host as unreachable. In this output, R3 at 192.168.5.2 is not unavailable; it is reachable and is reporting that it cannot reach 172.16.0.2. Check R3's connected and host routes, its interface toward R4, forwarding state, and return routing.

Neither asterisks nor an unreachable code alone proves that a router has failed. ICMP filtering, an access control list (ACL), control-plane policing, return-path problems, and response rate limiting can hide a hop or alter the result.

Cisco IOS traceroute output indicators

Output item	Meaning	Likely interpretation or next action
Round-trip time in milliseconds	Time for one probe and its response to complete.	Compare probes and hops for delay or loss patterns; one high value does not by itself prove a forwarding problem.
`*`	The probe timed out or no usable response was received.	Check the next hop, filtering, return routing, and whether the device intentionally suppresses traceroute responses.
`!H`	Host unreachable.	A responding device says the destination host cannot be reached; inspect destination addressing and routes.
`A`	Administratively prohibited response, commonly shown with an exclamation mark such as `!A`.	Look for an ACL or security policy rejecting the probe or traffic.
`Q`	Source quench indication.	A legacy and uncommon congestion-related response; do not treat it as a modern congestion-control mechanism.
`I`	User interruption.	The operator stopped the trace, commonly with the escape sequence.
`U`	Port unreachable, commonly shown as `!U`.	The destination or an intermediate device rejected the probe's port; interpret it according to the probe type and platform.
`N`	Network unreachable, commonly shown as `!N`.	Inspect the reporting router's route toward the destination network.
`P`	Protocol unreachable, commonly shown as `!P`.	The device does not support or permit the protocol used by the probe.
`T`	Timeout indication on platforms that display a timeout code.	Compare with asterisks and verify filtering, device load, and return-path behavior.
`?`	Unknown packet type or an unrecognized response indicator.	Check the IOS platform behavior, probe type, and relevant device configuration.

IOS output formatting and supported indicators can vary by software release and platform. Interpret the symbol together with the responding address and the position of the hop.

Traceroute troubleshooting workflow

Confirm the symptom. Run ping <destination-ip-address> and note whether the problem is total loss, intermittent loss, or only missing traceroute responses.
Identify the boundary. Record the last confirmed responding router and the next hop expected from the routing topology.
Verify interfaces and addressing. On the last known-good router and suspected next-hop device, run show ip interface brief. Check that relevant interfaces have the expected addresses and are operational.
Check routing. Run show ip route <destination-ip-address> on the source-side and suspected devices. Confirm the selected route, next hop, and any required return route.
Test with controlled sources. Enter ping to use extended ping prompts. Select an appropriate source address, repeat count, packet size, and destination to test each link or direction.
Inspect filtering. Run show access-lists and review ACLs or other security policies that could block the probe, the response, or the return traffic.
Classify the problem. Decide whether the evidence indicates a forwarding failure, a return-path problem, or only traceroute-response filtering. A successful ping with hidden hops often indicates the last case.
Use debugging carefully. If necessary, use debug ip icmp during a tightly controlled test. Debug output can consume CPU and generate substantial console traffic on production devices. Stop it immediately afterward with undebug all or the platform's equivalent.

Traceroute troubleshooting decision guide

Observed output pattern	Probable cause	Verification steps
Trace stops after a known router	Failure at the next link or router, a missing route, a return-path issue, or filtered responses.	Inspect the last router's route, verify interfaces and neighbor connectivity, and ping the next hop and destination with an appropriate source.
Host unreachable response	A router reports that the destination host cannot be reached.	Check host and connected routes, verify the target interface and address, and check forwarding and return routing.
Network unreachable response	The reporting device has no usable path to the destination network.	Run `show ip route`, verify dynamic or static route learning, and check the next-hop relationship.
Repeated timeouts	The device may be down, overloaded, filtering probes, rate limiting responses, or unable to return them.	Use ordinary and extended ping, inspect interfaces and ACLs, and test from both directions where possible.
Trace reaches destination but users report an application issue	Layer 3 forwarding works, but the application, port, DNS, firewall, server, or higher-layer service may be failing.	Test the required service and port separately; do not treat a successful traceroute as proof that the application works.

Important interpretation limits

A hop that does not answer may still forward transit traffic normally.
Some routers prioritize forwarding over generating diagnostic responses, so RTT values can be misleading when a device rate-limits control-plane traffic.
Different return interfaces, asymmetric routing, load balancing, and filtering can make the displayed path differ from a simple topology diagram.
Traceroute identifies responding Layer 3 points, not every switch, firewall function, tunnel endpoint, or physical link.

Exam-relevant notes

TTL is incremented to expose successive routers.
ICMP Time Exceeded commonly identifies an intermediate hop whose TTL reached zero.
The last responding hop is a troubleshooting boundary, not automatic proof of failure.
!H indicates host unreachable; !N indicates network unreachable; !P indicates protocol unreachable; !U indicates port unreachable; and !A indicates administratively prohibited traffic.
Always distinguish a forwarding failure from a device that simply filters traceroute-related responses.

Related IOS skills

Use show ip route concepts to compare the trace with the selected route, and review the OSI reference model when separating Layer 3 path problems from higher-layer application issues. ACL behavior is also important when diagnostic responses are filtered.