tracert and traceroute are path-evidence tools, not complete network maps
Windows tracert and Unix-like traceroute both exploit the IP TTL or hop-limit field to expose responding routed hops toward a destination. They are excellent for showing where probes receive responses and where those responses stop, but their output must be interpreted carefully. A missing response is not automatically a failed router, and a high time on one line is not automatically the place where user traffic is delayed.
The names differ by platform, but the diagnostic objective is the same
Windows commonly provides tracert. Unix-like operating systems commonly provide traceroute. Both discover responding Layer 3 hops by sending probes with progressively larger TTL values. The important AP Networking distinction is not the spelling of the command—it is understanding what the resulting hop list actually proves.
Windows
tracert example.com
Commonly uses ICMP Echo Request probes.
Unix-like
traceroute example.com
Traditional implementations commonly use UDP by default.
Shared mechanism
Progressively increasing TTL values reveal responding routers.
Traceroute creates hop visibility by intentionally causing packets to expire
Routers decrement the IPv4 TTL field as they forward packets. When TTL reaches zero, the router discards the packet and may return an ICMP Time Exceeded message. Traceroute takes advantage of that behavior deliberately.
The tool keeps increasing TTL until the destination produces the expected terminal response or the hop limit is reached.
Traceroute is a Layer 3 path view, not a switch-by-switch topology diagram
An ordinary Layer 2 switch forwards Ethernet frames without acting as an IP router for the transit packet. It does not become a TTL-expiration hop merely because the frame passed through it. This means a path containing five switches and three routers may display only the three routed hops.
Probe type can change the visible result even when the forwarding path stays the same
Traditional Unix-like traceroute commonly uses UDP probes, while Windows tracert commonly uses ICMP Echo Requests. Other implementations can use ICMP or TCP modes. Firewalls and routers may filter or rate-limit one probe type differently from another.
| Probe behavior | Possible outcome | Interpretation |
|---|---|---|
| ICMP allowed, UDP filtered | tracert shows more hops than UDP traceroute | Visibility difference, not necessarily path difference |
| UDP allowed, ICMP rate-limited | Unix traceroute looks cleaner | Control-plane policy may differ |
| TCP/443 probe allowed | TCP traceroute reaches destination | Useful when application path uses TCP/443 |
Swipe horizontally to see the probe comparison.
Each row usually represents one TTL value and multiple probe responses
The three times are separate probe-response round trips for that TTL value. The addresses are devices that responded to the probes, not a guarantee that every packet takes exactly that path forever.
An asterisk means “no expected response in time,” not “this router is dead”
A router can forward transit packets normally while choosing not to respond to TTL-expired probes, rate-limiting those responses, or having its replies filtered. The most important interpretation comes from what happens after the asterisk.
Because hops 4 and 5 respond, packets clearly continued past hop 3. Hop 3 is not proven failed.
Asterisks become more significant when loss of visibility continues to the destination
This output supports the statement that probe responses stop after hop 3. It does not yet prove hop 4 is broken. The cause could be filtering, routing failure, destination policy, or nonresponsive intermediate devices. Pair the trace with routing, firewall, and destination evidence.
Per-hop response time is not the same as one-way transit delay through that router
Traceroute measures the round-trip time between the source and the response generated for each probe. Routers may prioritize forwarding data packets over generating control-plane diagnostic replies. A router can therefore appear “slow” to traceroute while forwarding normal traffic quickly.
If hop 4 truly added roughly 170 ms of forwarding delay to every packet, later hops could not suddenly return around 30 ms. The isolated spike is stronger evidence of response prioritization than a transit bottleneck.
A delay increase matters more when it begins at one point and remains high afterward
This pattern is more consistent with a path segment where additional delay appears and remains part of the round trip. Even here, asymmetric return routing means you should avoid claiming the delay is definitely inside hop 4 itself.
The forward hop list and the measured round-trip time can involve different return paths
Internet routing does not require packets from A to B to use the same route as packets from B to A. Traceroute's listed hop comes from forward-path discovery, but the response time includes whatever path the reply takes back.
Traceroute becomes useful after local addressing and gateway reachability are established
If a client has an APIPA address, the wrong gateway, or cannot reach its local router, tracing a distant Internet host skips over an earlier failure. Start with source IP configuration and gateway reachability.
This sequence preserves known-good evidence and keeps the trace focused on the remote path.
Path discovery and route selection answer different questions
| Tool/artifact | Answers | Does not directly answer |
|---|---|---|
| Routing table | Which next hop/interface the local device selects | Every downstream hop across the network |
| Traceroute/tracert | Which routed devices respond as TTL increases | Why the local router selected its route |
| Ping | Whether tested ICMP echo exchange succeeds | Complete routed path |
Swipe horizontally to see the comparison.
Reverse DNS names are presentation data, not proof of routing behavior
Traceroute may display a hostname beside a responding IP address by performing a reverse DNS lookup. That name can be useful for orientation, but it is separate from the forwarding decision. A missing hostname does not mean the hop failed, and a hostname does not prove ownership, physical location, or path function.
One silent hop, destination still reachable
Hops 1 and 2 respond, hop 3 shows three asterisks, hops 4 through 7 respond, and the destination completes normally.
Inference: hop 3 did not provide expected diagnostic responses, but transit forwarding clearly continued. Investigating hop 3 as “down” would overstate the evidence.
Latency spike disappears at the next hop
Hop 5 reports about 220 ms while hop 6 and the destination report 35 ms.
Inference: hop 5's control-plane response is likely deprioritized or delayed. The trace does not support saying hop 5 adds 185 ms to every transit packet.
Latency rises and stays high through the destination
RTT is 12–15 ms through hop 4, jumps to approximately 90 ms at hop 5, and remains near 90–100 ms through the destination.
Inference: additional delay appears around that portion of the measured path. Because replies may return asymmetrically, collect more evidence before assigning blame to one router.
tracert succeeds but UDP traceroute is sparse
Windows tracert using ICMP displays eight hops. A Unix-like UDP traceroute from a comparable location shows many asterisks.
Inference: probe-protocol treatment differs somewhere along the path. Do not assume the underlying route changed merely because visibility changed.
The local gateway is unreachable before the trace starts
A client cannot ping its gateway and traceroute fails immediately.
Inference: the first unresolved dependency is local. Check addressing, subnet mask, wireless/cable state, VLAN attachment, and gateway reachability before interpreting remote path behavior.
A firewall can filter diagnostic probes while allowing the application itself
A site may allow TCP/443 to a web server while blocking ICMP Echo or high-numbered UDP probes used by traceroute. The web application can therefore work even if traceroute appears incomplete.
The destination application is the final requirement, not a perfect-looking trace
If the troubleshooting requirement is “Can the user reach the HTTPS service?”, verify HTTPS. Traceroute is supporting evidence. A clean trace with a failed application still leaves DNS, firewall, server-listener, TLS, and application-layer dependencies unresolved.
This is the same evidence discipline used throughout AP Networking troubleshooting: test the requirement you are actually trying to restore.
Two traces taken at different times can legitimately show different paths
Dynamic routing, load balancing, provider policy, maintenance, and path changes can alter which routers respond. A different trace later does not automatically indicate a problem. Compare whether the user-visible requirement, destination reachability, latency, and loss also changed.
Multiple probes can encounter different next hops in load-balanced networks
Some networks distribute flows across multiple equal-cost paths. Depending on how the network hashes probe traffic, traceroute may display different addresses across repeated runs or even within a hop position.
Treat this as a reminder that traceroute is a sampled observation of routed behavior, not a permanent physical diagram.
Know exactly what each traceroute observation proves
| Observation | Supports | Does not prove |
|---|---|---|
| Hop replies | That device returned the expected response | All traffic always uses that hop |
| * * * | No expected replies for those probes | Router is down |
| Single high RTT | Slow response from that hop | Transit packets incur same delay |
| Later hops respond | Probes progressed beyond earlier hop | Earlier hop is healthy in every way |
| Destination responds | Trace probe reached destination | Target application is functioning |
Swipe horizontally to see the evidence-boundary table.
The same trace symptom can come from multiple mechanisms
| Trace symptom | Plausible cause | Next discriminating evidence |
|---|---|---|
| One silent hop | ICMP filtering/rate limiting | Check later hops and destination |
| Silence from one point onward | Filtering, route failure, destination policy | Routing table, firewall log, reverse test |
| Persistent RTT increase | Added path delay or congestion | Ping/load tests, interface utilization |
| Different paths across runs | Dynamic routing/load balancing | Repeat under controlled conditions |
Swipe horizontally to see the differential table.
Find the first meaningful change without overclaiming the cause
A strong analysis says: hop 4 does not return expected responses; probes continue beyond it; round-trip time is substantially higher beginning with hop 5 and remains high to the destination. That supports a change in measured path conditions around that region but does not uniquely identify one failed router.
State observation, mechanism, boundary, and next evidence
Observation: identify exactly where output changes.
Mechanism: explain TTL expiration, probe type, or routing behavior.
Persistence: check whether loss or latency continues to later hops.
Boundary: say what the trace does not prove.
Next evidence: choose routing, firewall, interface, or application evidence.
Verification: retest the actual destination or application requirement.
A strong answer avoids reading traceroute too literally
- An asterisk does not automatically mean a router is down.
- A high time on one hop does not automatically identify a bottleneck.
- Layer 2 switches do not normally appear as routed hops.
- Different probe protocols can produce different visible traces.
- Forward and return paths can be asymmetric.
- A successful trace does not prove the application itself works.
One trace is a snapshot; repeated traces under controlled conditions reveal much more
Traceroute becomes more useful when you compare it against a known-good baseline or repeat it during both healthy and degraded periods. A single path may show a temporary routing change, one rate-limited hop, or a momentary latency spike that disappears immediately. Repeated observations help separate stable path characteristics from transient behavior.
For a useful comparison, keep the source, destination, probe method, and general test conditions as consistent as possible. Then compare hop count, where response loss begins, whether latency changes persist to later hops, and whether the destination application is also affected.
That comparison is stronger than saying “hop 4 is slow.” It shows that the measured round-trip time increases around the same point and remains elevated to the destination during the problem period. The next discriminating evidence could be interface utilization, queue drops, provider status, or a reverse-path test.
24 Tracert vs. Traceroute digital flashcards
Practice TTL behavior, Windows vs. Unix-like probe types, asterisks, latency interpretation, asymmetry, route-table differences, firewall effects, evidence boundaries, and exam traps.