Windows tracert Command Explained

What tracert is doing

tracert (trace route) sends ICMP echo requests with increasing TTL values toward the destination. Each router that decrements TTL to zero returns an ICMP Time Exceeded message, which Windows displays as that hop’s latency. The final hop typically answers with ICMP Echo Reply (same family as ping), so the last line looks like normal ping RTTs.

Common switches

Switch	Meaning	Typical use
`-d`	Do not resolve addresses to hostnames	Faster runs; DNS issues won’t mask routing
`-h maximum_hops`	Cap hop count (default 30)	Shorter tests; avoid long loops
`-w timeout_ms`	Wait time per reply (default 4000 ms)	Satellite or lossy paths; don’t set absurdly low on WAN
`-4` / `-6`	Force IPv4 or IPv6	Dual-stack ambiguity; match your target record type
`-j host-list`	Loose source route (rarely honored)	Most paths ignore—treat as legacy

Reading the output

Each hop shows up to three RTT samples (Windows probes multiple times per TTL). A column of * means no reply before the wait window—often ICMP rate-limited, filtered, or an asymmetric return path, not necessarily a “dead” router. A single high spike on a middle hop often reflects control-plane de-prioritization of ICMP on that device; compare with end-to-end application latency (ping to the destination, or TCP-based tools) before blaming that hop.

When tracert lies (a little)

Many routers treat traceroute ICMP differently from customer TCP/UDP. MPLS cores may show one public hop where labels switched internally. Load-balanced paths can make successive runs differ. Corporate VPNs and split tunneling change which interface and resolver apply—run traces with VPN on and off and label the interface in your notes.

Alternatives on Windows

pathping combines traceroute-style discovery with sustained per-hop loss statistics—useful for intermittent loss. In PowerShell, Test-NetConnection -ComputerName host -TraceRoute performs a similar hop list (behavior varies by OS build; still ICMP-oriented). For TCP-shaped paths, external tools or psping-style utilities may better match real application RTT.

Frequently Asked Questions

Q.What does * mean in tracert output?

No ICMP reply arrived before the per-probe timeout—common when a hop rate-limits or drops ICMP time-exceeded, or when return paths are asymmetric. It does not by itself prove the link is down.

Q.Should I use tracert -d?

Yes when DNS is slow, wrong, or you only care about IP-level routing. -d skips reverse lookups so the trace finishes faster and avoids misleading names on shared PTRs.

Q.How is tracert different from Linux traceroute?

Windows tracert is ICMP-based by default. Many Linux traceroute implementations default to UDP high ports or support -I ICMP; middleboxes may treat them differently, so cross-platform comparisons are not always apples-to-apples.

Q.When should I use pathping instead of tracert?

Use pathping when you need loss statistics aggregated over many probes after the route is discovered—better for flaky links than a single tracert snapshot.

Q.Does tracert require Administrator?

Usually no for basic use from an elevated or standard command prompt. Corporate policy, security software, or specialized options can still block ICMP egress or replies.

Q.Why does one middle hop show huge latency but ping to the final site is fine?

Many devices slow-path or de-prioritize ICMP TTL-exceeded generation. Treat middle-hop spikes cautiously; validate with end-to-end TCP or application-layer measurements.

Q.How do I trace over IPv6?

Use tracert -6 target where the target resolves to IPv6 or supply a literal IPv6 address. Ensure the interface has a global IPv6 and that firewalls allow ICMPv6 hop-limit exceeded and echo where applicable.

Q.Why does tracert stop before reaching the target?

You may have hit the hop limit (-h), encountered a blackhole route, or reached a segment that drops ICMP while still forwarding TCP—try pathping, adjust -w, test from another network, or compare with a TCP-based trace tool.