I want to make these points clear before we begin:
- Traceroute reports only the outbound routing path, not the return path
- Latency reported by traceroute is round-trip, but only the outbound path is recorded, the return path is not recorded.
- Traceroute is NOT intended for calculating packet loss.
- Traceroute is NOT intended for determining latency.
- Traceroute will not report routing or routes.
- Switches, bridges, MUXs and other devices operating below the IP layer (Network layer) are transparent to Traceroute and will not be seen.
Traceroute was never inteded to do any of the above, it was only meant to expose the list of routers between two endpoints to determine if there is any sort of network problem. Traceroute will not indicate the exact source nor will it identify exactly what the problem is, it only assists you in pinning down the approximate location of whatever problem exists.
When performing a traceroute, you should always use a trace done in both directions (here to there, there back to here). Performing a traceroute in both directions is the only way to reveal asymmetric routing problems.
When reading the output from traceroute, keep in mind that the information is from only the interfaces that received the traceroute/UDP packets, NOT the interface that transmitted the packet (which may be the actual problem).
WINDOWS
Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] target_name
Options: -d Do not resolve addresses to hostnames. -h maximum_hops Maximum number of hops to search for target. -j host-list Loose source route along host-list. -w timeout Wait timeout milliseconds for each reply.
C:\tracert <hostname> C:\tracert <IP address>
UNIX/LINUX/BSD
Usage: traceroute [ -dFISdnrvx ] [ -f first_ttl ] [ -g gateway ] [ -i iface ] [ -M first_ttl ] [ -m max_ttl ] [ -P proto ] [ -p port ] [ -q nqueries ] [ -s src_addr ] [ -t tos ] [ -w waittime ] [ -z pausemsecs ] host [ packetlen ]
$ traceroute <hostname> $ traceroute <IP address>