traceroute [ip]
Traces the route packets take from the Nexus switch to a destination IP address, showing each hop along the path.
Overview
The traceroute command is a fundamental network diagnostic tool used to trace the path that IP packets take from a source device to a destination host. It operates by sending packets with progressively increasing Time-To-Live (TTL) values. Each router along the path decrements the TTL; when the TTL reaches zero, the router discards the packet and sends an ICMP Time Exceeded message back to the source. By recording the source IP of these ICMP messages, traceroute builds a list of hops. On Cisco NX-OS (Nexus), traceroute uses ICMP echo requests by default, unlike classic Cisco IOS which uses UDP datagrams to high-numbered ports. This distinction is important for firewall and ACL configurations. Traceroute is invaluable for verifying network paths, identifying routing loops, detecting asymmetric routing, and pinpointing points of packet loss or high latency. In a troubleshooting workflow, it is often used after ping to isolate connectivity issues. For example, if ping to a remote host fails, traceroute can show where the path stops. If ping succeeds but performance is poor, traceroute can reveal which hop introduces delay. On Nexus switches, the command supports additional parameters such as VRF selection, source IP specification, custom TTL ranges, port numbers (for UDP-based traces), timeout values, probe count, numeric output (to skip DNS resolution), and verbose output. These options allow fine-grained control for advanced diagnostics. The command is available in EXEC mode and does not require privileged access, though some parameters may require higher privileges. Understanding how to interpret traceroute output is a key skill for network engineers, especially in complex environments with multiple routing protocols and VRFs.
traceroute [ip] [vrf vrf-name] [source source-ip] [ttl min-ttl max-ttl] [port port-number] [timeout seconds] [probe count] [numeric] [verbose]When to Use This Command
- Verify the path from a Nexus switch to a remote server during initial network deployment.
- Identify where packet loss or high latency occurs in a multi-hop routed network.
- Troubleshoot asymmetric routing by comparing traceroute results from different sources.
- Confirm that traffic is being forwarded through expected next-hop devices after routing changes.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| ip | ip-address | hostname | The destination IP address or hostname to trace. If a hostname is provided, it is resolved via DNS. The destination must be reachable via the routing table. |
| vrf | vrf vrf-name | Specifies the Virtual Routing and Forwarding (VRF) instance to use for the trace. This is required if the destination is in a non-default VRF. It ensures the probes are sent using the correct routing table. |
| source | source source-ip | Sets the source IP address for the probe packets. This is useful when the switch has multiple IP addresses and you want to test connectivity from a specific interface or IP. |
| ttl | ttl min-ttl max-ttl | Defines the minimum and maximum TTL values. The trace starts at min-ttl and ends at max-ttl. This allows you to skip initial hops or limit the trace to a specific range. |
| port | port port-number | Specifies the destination UDP port for the probes. By default, NX-OS uses ICMP, but if you specify a port, it switches to UDP. This can be used to test firewall rules or specific services. |
| timeout | timeout seconds | Sets the timeout in seconds for each probe. Default is 3 seconds. Increase this for high-latency links to avoid false timeouts. |
| probe | probe count | Number of probes sent per hop. Default is 3. Increasing the count can provide more accurate latency measurements. |
| numeric | numeric | Disables DNS resolution for each hop IP. This speeds up the trace and avoids delays if DNS is slow or unavailable. |
| verbose | verbose | Enables verbose output, which includes additional information such as the IP address of the interface that sent the ICMP Time Exceeded message. |
Command Examples
Basic traceroute to a remote host
traceroute 10.1.1.1traceroute to 10.1.1.1 (10.1.1.1), 30 hops max, 40 byte packets 1 192.168.1.1 (192.168.1.1) 1.234 ms 1.123 ms 1.098 ms 2 10.0.0.2 (10.0.0.2) 2.456 ms 2.345 ms 2.234 ms 3 10.1.1.1 (10.1.1.1) 3.567 ms 3.456 ms 3.345 ms
Each line shows a hop (router) along the path. The first column is the hop number, followed by the IP address and hostname (if resolved). The three time values are round-trip times for each of three probes. Healthy values are low and consistent; high or missing values indicate issues.
Traceroute with VRF and source IP
traceroute 172.16.0.1 vrf management source 192.168.100.1traceroute to 172.16.0.1 (172.16.0.1) from 192.168.100.1, 30 hops max, 40 byte packets 1 192.168.100.254 (192.168.100.254) 0.567 ms 0.543 ms 0.521 ms 2 10.10.10.1 (10.10.10.1) 1.234 ms 1.198 ms 1.187 ms 3 172.16.0.1 (172.16.0.1) 2.345 ms 2.321 ms 2.300 ms
The VRF and source IP are specified. The output shows the path from the management VRF, starting from the source IP. This is useful when the switch has multiple routing tables.
Understanding the Output
The traceroute output displays each hop along the path to the destination. The first line shows the destination IP, maximum hops (default 30), and packet size. Each subsequent line corresponds to a hop number (starting at 1). For each hop, the IP address (and hostname if DNS resolution is enabled) is shown, followed by three round-trip time (RTT) measurements in milliseconds. These three values represent the time for each of three probe packets sent to that hop. If a probe times out, an asterisk (*) is displayed instead of a time. Healthy output shows consistent, low RTTs (e.g., <10 ms for local hops, <100 ms for WAN hops) and no asterisks. Problematic indicators include high RTTs (indicating congestion or slow links), asterisks (indicating packet loss or unreachable hops), or a sudden jump in RTT (suggesting a slow link or routing issue). The command stops when the destination is reached or the maximum hop count is exceeded. If the destination is unreachable, the last hop may show '!' or 'H' indicating host unreachable, or 'N' for network unreachable.
Configuration Scenarios
Tracing a route through a management VRF
A Nexus switch has a management VRF (management) with a separate routing table. You need to trace the path to a management server at 10.10.10.100.
Topology
[Nexus] -- mgmt0 (192.168.1.1) -- [Management Switch] -- [Server 10.10.10.100]Steps
- 1.Enter EXEC mode on the Nexus switch.
- 2.Issue the command 'traceroute 10.10.10.100 vrf management'.
- 3.Observe the output to see the path through the management network.
! No configuration needed; command is run in EXEC mode.
Verify: The output should show the first hop as the management gateway (e.g., 192.168.1.254) and eventually reach 10.10.10.100.
Watch out: If you omit the VRF, the command will use the default VRF and likely fail with 'Destination unreachable' because the route is not in the default table.
Using UDP traceroute to test firewall rules
A firewall between the Nexus and a server is configured to allow UDP traffic on port 33434. You want to verify that traceroute packets are permitted.
Topology
[Nexus] -- [Firewall] -- [Server 10.20.30.40]Steps
- 1.Enter EXEC mode.
- 2.Issue 'traceroute 10.20.30.40 port 33434' to use UDP probes.
- 3.Check if all hops respond; if a hop shows asterisks, the firewall may be dropping the probes.
! No configuration needed.
Verify: Successful trace with all hops responding indicates the firewall allows the UDP probes.
Watch out: Some firewalls may block ICMP but allow UDP; using the port option can bypass ICMP restrictions.
Troubleshooting with This Command
When troubleshooting connectivity issues on Cisco NX-OS, traceroute is a go-to tool after ping. Start by pinging the destination; if ping fails, use traceroute to see where the path stops. If ping succeeds but there are performance issues, traceroute can reveal latency spikes. On Nexus, remember that by default traceroute uses ICMP. If you suspect ICMP is being filtered, try using the 'port' option to switch to UDP. Also, if the destination is in a non-default VRF, always specify the VRF; otherwise, the command will fail. When interpreting output, look for patterns: a single asterisk at a hop may indicate a device that does not respond to ICMP Time Exceeded (common on some routers). Multiple consecutive asterisks suggest a firewall or ACL dropping probes. A sudden increase in RTT at a particular hop often points to a congested or slow link. If the trace stops at a hop and subsequent hops show '!H' or '!N', it means the router at that hop cannot reach the destination (host or network unreachable). This could be due to a missing route or a routing loop. To isolate asymmetric routing, run traceroute from both ends and compare paths. On Nexus, you can also use the 'verbose' option to see the interface IP that sends the ICMP error, which helps identify which interface on the router is responding. For high-latency links, increase the timeout value to avoid premature timeouts. If DNS resolution is slow, use the 'numeric' option to skip it. In complex environments with multiple VRFs, always double-check the VRF context. Finally, remember that traceroute is a layer 3 tool; it cannot traverse layer 2 switches unless they have an IP address and respond to ICMP. If you have a pure layer 2 segment, traceroute may show the next layer 3 hop directly.
CCNA Exam Tips
Remember that traceroute uses ICMP echo requests by default on NX-OS, unlike IOS which uses UDP. This can affect firewall filtering.
Know how to interpret asterisks: a single asterisk may be a transient issue, but consecutive asterisks often indicate a firewall dropping probes or a routing loop.
Be familiar with the 'vrf' option: on Nexus, you must specify the VRF if the destination is not in the default VRF.
Common Mistakes
Forgetting to specify the VRF when the destination is in a non-default VRF, causing 'Destination unreachable' errors.
Assuming traceroute uses UDP (as in IOS) and misconfiguring ACLs; NX-OS uses ICMP by default.
Interpreting a single asterisk as a failure; it may be due to a device that does not respond to probes but still forwards packets.
Platform Notes
On Cisco NX-OS, the traceroute command differs from classic IOS in several ways. First, the default probe type is ICMP echo requests, whereas IOS uses UDP to high ports (33434+). This means that on Nexus, traceroute may work even if UDP is blocked, but may fail if ICMP is blocked. To use UDP on Nexus, you must explicitly specify the 'port' parameter. Second, NX-OS requires the 'vrf' keyword to specify a non-default VRF; in IOS, you often use 'vrf' after the destination or as a separate keyword. Third, the output format is slightly different: NX-OS shows 'traceroute to ...' with the source IP if specified, while IOS shows 'Type escape sequence to abort.' Additionally, NX-OS supports the 'source' parameter to set the source IP, which is also available in IOS but with different syntax. On Nexus, the command is available in EXEC mode without needing to enter privileged EXEC. For equivalent commands on other platforms: on Linux, use 'traceroute' (which uses UDP by default) or 'mtr'; on Windows, use 'tracert' (ICMP). In terms of version differences, NX-OS versions prior to 7.x may have slightly different parameter support; always check the documentation for your specific version. Overall, understanding these nuances is critical for accurate troubleshooting on Nexus switches.
Related Commands
Practice for the CCNA 200-301
Test your knowledge with hundreds of CCNA practice questions covering all exam domains.
Practice CCNA Questions