traceroute [ip] source [intf]
Traces the route packets take to a destination IP address, using a specified source interface for the outgoing probes, to test path connectivity and identify routing issues.
Definition: traceroute [ip] source [intf] is a Cisco IOS privileged exec command. Traces the route packets take to a destination IP address, using a specified source interface for the outgoing probes, to test path connectivity and identify routing issues.
Overview
The 'traceroute [ip] source [intf]' command in Cisco IOS is a powerful diagnostic tool used to trace the path that IP packets take from the router to a specified destination, while forcing the source address of the probes to be the IP address of a designated interface. This variant is particularly useful in multi-homed or complex routing environments where the default source address selection might not reflect the desired path or where you need to test connectivity from a specific network segment. The command works by sending a series of UDP packets (or ICMP echo requests, depending on the IOS version) with incrementally increasing Time-to-Live (TTL) values.
Each router along the path decrements the TTL; when it reaches zero, the router discards the packet and sends back an ICMP Time Exceeded message, revealing its IP address. This process continues until the destination is reached, which responds with an ICMP Port Unreachable (for UDP probes) or an ICMP Echo Reply (for ICMP probes). The 'source' option allows the engineer to specify the source interface, ensuring that the source IP in the probes matches the IP of that interface, which is critical when testing policy-based routing, firewall rules, or reverse path forwarding checks.
This command is often preferred over the standard 'traceroute' when you need to verify that traffic from a specific subnet or interface can reach a destination, or when troubleshooting asymmetric routing. It fits into a broader troubleshooting workflow that typically starts with 'ping' for basic reachability, then escalates to 'traceroute' for path discovery, and finally uses 'debug ip packet' or 'show ip route' for deeper analysis. The command runs in Privileged EXEC mode (enable) and does not alter the running configuration; it is purely a diagnostic tool.
Output is displayed incrementally as each hop responds, which can be interrupted with Ctrl+Shift+6. Note that some routers may not respond to traceroute probes due to security policies, resulting in asterisks (*) in the output. Understanding this command is essential for CCNA and CCNP candidates as it directly applies to real-world network troubleshooting and is a frequent topic in certification exams.
traceroute [ip] source [intf]When to Use This Command
- Verify the path from a specific interface (e.g., loopback) to a remote server when multiple paths exist.
- Troubleshoot asymmetric routing by forcing probes out a particular interface.
- Test connectivity from a management interface to a core network device.
- Validate that traffic from a specific subnet (via its interface) reaches a destination correctly.
Parameters
| Parameter | Syntax | Description |
|---|---|---|
| ip | A.B.C.D | The destination IP address to trace. This can be any valid IPv4 address, such as 10.0.0.1 or 192.168.1.1. A common mistake is using a hostname without first ensuring DNS resolution is configured, which may cause the command to fail or produce unexpected results. |
| source | interface-type interface-number | Specifies the source interface whose IP address will be used as the source of the traceroute probes. For example, 'GigabitEthernet0/0' or 'Loopback0'. The interface must have an IP address configured and be in an up/up state; otherwise, the command will fail. A common mistake is using an interface that is down or has no IP address, resulting in an error message. |
Command Examples
Traceroute from Loopback0 to 8.8.8.8
traceroute 8.8.8.8 source Loopback0Type escape sequence to abort. Tracing the route to 8.8.8.8 VRF info: (vrf in name/id, vrf out name/id) 1 192.168.1.1 4 msec 4 msec 4 msec 2 10.0.0.1 8 msec 8 msec 8 msec 3 172.16.0.1 12 msec 12 msec 12 msec 4 8.8.8.8 16 msec 16 msec 16 msec
Line 1: First hop is 192.168.1.1 with 4 ms round-trip time for each probe. Line 2: Second hop 10.0.0.1 with 8 ms. Line 3: Third hop 172.16.0.1 with 12 ms. Line 4: Destination 8.8.8.8 reached in 16 ms. Each line shows hop number, IP address, and three probe times. Increasing times indicate normal latency accumulation; sudden jumps may indicate congestion or suboptimal paths.
Traceroute with source interface GigabitEthernet0/1 to 10.10.10.1
traceroute 10.10.10.1 source GigabitEthernet0/1Type escape sequence to abort. Tracing the route to 10.10.10.1 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.0.2 2 msec 2 msec 2 msec 2 10.0.0.5 6 msec 6 msec 6 msec 3 * * * 4 10.10.10.1 20 msec 20 msec 20 msec
First hop 10.0.0.2 (2 ms), second hop 10.0.0.5 (6 ms). Third hop shows asterisks (* * *) meaning no response within timeout (possible firewall or routing issue). Fourth hop reaches destination 10.10.10.1 (20 ms). Asterisks indicate packet loss or filtering at that hop; if destination is reached, the path is still functional but that hop may be hidden.
Understanding the Output
The output lists each hop (router) along the path to the destination. Each line shows the hop number, the IP address of the responding router, and three round-trip times (in milliseconds) for three probes. Times are typically low (1-10 ms) on LANs and increase with distance.
Values over 100 ms may indicate high latency or congestion. Asterisks (*) mean the probe timed out (no response), which could be due to ICMP filtering, packet loss, or a routing loop. If the destination is reached, asterisks at intermediate hops are often due to security policies.
The source interface ensures probes originate from that interface's IP address, which is useful for testing specific paths or when multiple IPs exist on the router.
Configuration Scenarios
Tracing path from a specific loopback interface to a remote server
A network engineer needs to verify that traffic sourced from a management loopback interface (e.g., Loopback0 with IP 10.255.255.1) can reach a remote server at 203.0.113.10. The router has multiple interfaces, and the default source might be the outbound interface, which could be different.
Topology
R1(Lo0:10.255.255.1)---Gi0/0(10.0.12.1)---(10.0.12.2)Gi0/0 R2---Gi0/1(192.168.1.1)---(192.168.1.2)Server(203.0.113.10)Steps
- 1.Step 1: Enter privileged EXEC mode: Router> enable
- 2.Step 2: Initiate traceroute with source interface: Router# traceroute 203.0.113.10 source Loopback0
- 3.Step 3: Observe the output for each hop. The first hop should be the next-hop router (R2's Gi0/0 IP 10.0.12.2), then subsequent hops until the destination.
! No configuration is required; this is a diagnostic command. Router# traceroute 203.0.113.10 source Loopback0
Verify: The output should show the path with IP addresses of each hop. For example: Type escape sequence to abort. Tracing the route to 203.0.113.10 VRF info: (vrf in name/id, vrf out name/id) 1 10.0.12.2 1 msec 1 msec 1 msec 2 192.168.1.2 2 msec 2 msec 2 msec 3 203.0.113.10 3 msec 3 msec 3 msec
Watch out: If the source interface is not up/up, the command will fail with 'Interface not usable' or similar error. Always verify the interface status with 'show ip interface brief' before using it as a source.
Troubleshooting asymmetric routing from a specific VLAN interface
A router-on-a-stick configuration has multiple subinterfaces for different VLANs. Traffic from VLAN 10 (subinterface Gi0/0.10 with IP 10.10.10.1) to a destination at 172.16.0.1 is taking an unexpected path. The engineer wants to force the traceroute to use the VLAN 10 source IP to see the actual path.
Topology
R1(Gi0/0.10:10.10.10.1/24)---(Gi0/0)SW1---(VLAN10)Host(10.10.10.100) and R1(Gi0/0.20:10.10.20.1/24)---(Gi0/0)SW1---(VLAN20)Host(10.10.20.100). R1 connects to WAN via Gi0/1(192.168.1.1).Steps
- 1.Step 1: Enter privileged EXEC mode: Router> enable
- 2.Step 2: Run traceroute with source subinterface: Router# traceroute 172.16.0.1 source GigabitEthernet0/0.10
- 3.Step 3: Compare the output with a traceroute without the source option to identify differences in the path.
! No configuration needed. Router# traceroute 172.16.0.1 source GigabitEthernet0/0.10
Verify: The output should show the path from the VLAN 10 perspective. For example: Type escape sequence to abort. Tracing the route to 172.16.0.1 1 192.168.1.2 1 msec 1 msec 1 msec 2 10.0.0.1 2 msec 2 msec 2 msec 3 172.16.0.1 3 msec 3 msec 3 msec
Watch out: If the subinterface is not in 'up/up' state (e.g., the VLAN is not present on the switch), the command will fail. Also, ensure that the subinterface has an IP address configured; otherwise, the source IP will be undefined.
Troubleshooting with This Command
When using 'traceroute [ip] source [intf]' for troubleshooting, the primary goal is to identify where packets are being dropped, delayed, or misrouted. A healthy output shows each hop responding with round-trip times (RTT) in milliseconds, typically with three probes per hop. The first hop should be the next-hop router, and subsequent hops should progressively get closer to the destination.
Problem indicators include asterisks (*) indicating no response from a hop, which could be due to firewall filtering, ICMP rate-limiting, or a routing loop. High RTT values (e.g., >100 ms) may indicate congestion or suboptimal paths. If the trace stops at a certain hop and then shows asterisks, the issue is likely at that hop or beyond.
Focus on the IP addresses in the output: if a hop shows an unexpected IP (e.g., a private address when expecting a public one), there may be a routing issue or misconfiguration. Common symptoms this command helps diagnose include: asymmetric routing (where the return path differs), policy-based routing not taking effect, or a specific interface not being used as the source. The step-by-step diagnostic flow: 1) Start with a basic 'ping' to confirm reachability. 2) Use 'traceroute' without source to see the default path. 3) Use 'traceroute [ip] source [intf]' to test from a specific interface. 4) If asterisks appear, try increasing the timeout or using numeric display (e.g., 'traceroute ip 203.0.113.10 source Loopback0 numeric'). 5) Correlate with 'show ip route' to verify the routing table for the destination and source IP. 6) Use 'show ip interface [intf]' to confirm the interface is up and has the correct IP. 7) If needed, use 'debug ip packet' with an ACL to capture traffic from the source IP to the destination, but be cautious in production.
The output of 'traceroute' can also be correlated with 'show ip cef' to verify hardware forwarding paths. Remember that some routers may not respond to traceroute probes due to security policies, so asterisks do not always indicate a problem; they may simply mean the router is configured to not send ICMP Time Exceeded messages. In such cases, a traceroute from the destination back to the source can help confirm bidirectional connectivity.
CCNA Exam Tips
CCNA exam tip: The 'source' option forces the traceroute to use the IP of the specified interface as the source address; this is tested in troubleshooting scenarios.
CCNA exam tip: Asterisks in output do not always mean failure; if the destination is reached, they may indicate a device that does not respond to ICMP time-exceeded messages.
CCNA exam tip: Traceroute uses UDP probes by default on Cisco IOS (destination port 33434+); the 'source' option does not change the protocol.
CCNA exam tip: You can abort a traceroute with Ctrl+Shift+6, then X.
Common Mistakes
Mistake 1: Forgetting to specify the source interface when multiple paths exist, leading to misleading results (e.g., using management interface instead of the intended data interface).
Mistake 2: Confusing 'source' with 'destination' — the source interface must be a valid interface on the local router.
Mistake 3: Assuming asterisks always indicate a broken path; they may simply be due to ICMP filtering at that hop.
traceroute [ip] source [intf] vs ping [ip]
Both `traceroute` and `ping` are essential diagnostic tools, but they serve distinct purposes: `ping` tests end-to-end reachability and round-trip time, while `traceroute` reveals the path packets take, highlighting each hop. They are often used together to isolate network issues, but their output and behavior differ significantly.
| Aspect | traceroute [ip] source [intf] | ping [ip] |
|---|---|---|
| Scope | Traces path per hop | Tests end-to-end reachability |
| Protocol | Uses UDP probes by default (or ICMP with extended options) | Uses ICMP Echo Request/Reply |
| Output | Lists each router hop with latency and identity | Displays success/failure and RTT statistics |
| Usage | Debug routing asymmetries or packet loss at specific hops | Quick connectivity check or latency measurement |
| Impact | Generates multiple probes; may be filtered by firewalls | Lightweight; commonly permitted in ACLs |
| Source Interface | Allows specifying a source interface for probes | Uses the closest interface's IP by default |
Use `traceroute [ip] source [intf]` when you need to identify the exact path packets take from a specific source interface, especially for troubleshooting asymmetric routing or hop-by-hop latency.
Use `ping [ip]` when you need a quick, reliable test of end-to-end reachability and round-trip time without traversing hop-level details.
Platform Notes
In IOS-XE (e.g., Catalyst 9000 switches, ISR 4000 series), the 'traceroute' command syntax is identical to classic IOS, but the output may include additional VRF information if VRF-aware. For example: 'traceroute vrf Mgmt-intf 203.0.113.10 source Loopback0'. The source interface option works the same.
In NX-OS (e.g., Nexus switches), the equivalent command is 'traceroute [ip] source-interface [intf]' or 'traceroute [ip] vrf [vrf-name] source-interface [intf]'. For example: 'traceroute 203.0.113.10 source-interface loopback0'. Note that NX-OS uses 'source-interface' instead of 'source'.
On Cisco ASA firewalls, the command is 'traceroute' but the source interface is specified differently: 'traceroute [destination] source [interface_name]' (e.g., 'traceroute 203.0.113.10 source inside'). The ASA does not support the 'source' keyword in the same position; it uses a different syntax. In IOS-XR (e.g., ASR 9000, CRS), the command is 'traceroute [destination] source [interface]' but the output format is different, and the command is available in EXEC mode.
For example: 'traceroute 203.0.113.10 source Loopback0'. However, IOS-XR may require the 'vrf' keyword if the destination is in a non-default VRF. There are no significant differences between IOS 12.x, 15.x, and 16.x for this command, though newer versions may support additional options like 'numeric' or 'timeout'.
Always check the specific platform documentation for exact syntax.
Related Commands
ping [ip]
The ping command sends ICMP echo requests to a destination IP address to test network connectivity and measure round-trip time.
show ip route
Displays the IP routing table showing all known routes, their source protocols, administrative distances, metrics, next-hops, and outgoing interfaces.
traceroute [ip]
Traces the route packets take from the source device to a destination IP address, showing each hop along the path, used to diagnose network path issues and latency.
Practice for the CCNA 200-301
Test your knowledge with practice questions covering all CCNA 200-301 exam domains.
Practice CCNA 200-301 Questions