Ever wondered how a packet traveled from your computer to a website? Or, why in some circumstances it takes longer to get to google.com than it did the day before? Some of the issues are due to routers that make up the Internet and sometimes you can thank your ISP for the slow downs. With the traceroute (tracert in Windows), you can follow a packets round-trip from computer to server and back. The traceroute tool will display how many hops (the amount of routers or intermediate devices the packet traveled through to get to the destination) the packet took, the IP address if resolvable of each router along the way, and the amount of time it took to reach each intermediate device.
The traceroute utility, like most utilities has many flag options, here is a filtered list of the most useful pieces:
traceroute [ -46dFITnreAUV ] [ -f first_ttl ] [ -g gate,... ] [ -i device ]
[ -m max_ttl ] [ -N squeries ] [ -p port ] [ -t tos ] [ -l flow_label ]
[ -w waittime ] [ -q nqueries ] [ -s src_addr ] [ -z sendwait ] host [ packetlen ]
Options:
-4 Use IPv4
-6 Use IPv6
-d --debug Enable socket level debugging
-F --dont-fragment Do not fragment packets
-g gate,... --gateway=gate,...
Route packets through the specified gateway
(maximum 8 for IPv4 and 127 for IPv6)
-I --icmp Use ICMP ECHO for tracerouting
-T --tcp Use TCP SYN for tracerouting
-i device --interface=device
Specify a network interface to operate with
-m max_ttl --max-hops=max_ttl
Set the max number of hops (max TTL to be
reached). Default is 30
-n Do not resolve IP addresses to their domain names
-p port --port=port Set the destination port to use. It is either
initial udp port value for "default" method
(incremented by each probe, default is 33434), or
initial seq for "icmp" (incremented as well,
default from 1), or some constant destination
port for other methods (with default of 80 for
"tcp", 53 for "udp", etc.)
-q nqueries --queries=nqueries
Set the number of probes per each hop. Default is
3
-A --as-path-lookups Perform AS path lookups in routing registries and
print results directly after the corresponding
addresses
-U --udp Use UDP to particular port for tracerouting
(instead of increasing the port per each probe),
default port is 53
-P prot --protocol=prot Use raw packet of protocol prot for tracerouting
--mtu Discover MTU along the path being traced. Implies
`-F -N 1
--back Guess the number of hops in the backward path and
print if it differs
While it may look daunting I will outline some basic uses of the tool. To execute a basic traceroute:
$ traceroute google.com
traceroute to google.com (74.125.53.104), 30 hops max, 60 byte packets
1 debian (192.168.3.1) 0.180 ms 0.142 ms 0.135 ms
2 x.x.x.x (x.x.x.x) 7.162 ms 7.189 ms 7.448 ms
3 rd2cv-ge7-1-0-2.gv.shawcable.net (64.59.162.242) 13.339 ms 13.364 ms 17.688 ms
4 rc1wt-pos3-0-0.wa.shawcable.net (66.163.77.182) 19.773 ms 20.056 ms 20.039 ms
5 rc6wt-tge0-15-0-0.wa.shawcable.net (66.163.68.46) 22.592 ms 22.636 ms 22.613 ms
6 74.125.48.233 (74.125.48.233) 19.759 ms 19.267 ms 19.325 ms
7 209.85.249.34 (209.85.249.34) 19.316 ms 209.85.249.32 (209.85.249.32) 17.528 ms 209.85.249.34 (209.85.249.34) 56.147 ms
8 66.249.94.199 (66.249.94.199) 15.776 ms 66.249.94.201 (66.249.94.201) 15.752 ms 66.249.94.197 (66.249.94.197) 19.818 ms
9 216.239.46.212 (216.239.46.212) 26.981 ms 216.239.46.200 (216.239.46.200) 26.855 ms 216.239.46.208 (216.239.46.208) 69.883 ms
10 64.233.174.123 (64.233.174.123) 26.841 ms 64.233.174.129 (64.233.174.129) 26.769 ms 216.239.48.167 (216.239.48.167) 26.754 ms
11 72.14.232.10 (72.14.232.10) 31.015 ms 72.14.232.70 (72.14.232.70) 27.408 ms 26.492 ms
12 pw-in-f104.1e100.net (74.125.53.104) 25.626 ms 25.652 ms 25.614 ms
Note: I have replaced my IP address with X’s, whereas when you run your traceroute you will see your route able IP.
So what do we make of this? As I mentioned above, we are given the hop count, IP address of the router, and 3 ‘pings’ to each router and the time taken for an average. Each hop in this list is a router that our packet has traversed to get to its destination. The traceroute output also gives us some geographical information just from showing the hostnames of these intermediate devices. For example:
3 rd2cv-ge7-1-0-2.gv.shawcable.net (64.59.162.242) 13.339 ms 13.364 ms 17.688 ms
4 rc1wt-pos3-0-0.wa.shawcable.net (66.163.77.182) 19.773 ms 20.056 ms 20.039 ms
5 rc6wt-tge0-15-0-0.wa.shawcable.net (66.163.68.46) 22.592 ms 22.636 ms 22.613 ms
Hop 3 has “gv.shawcable”, or greater Vancouver, then the next packet traverses the border into “wa.shawcable” at hop 4 – Washington state. Now that we know the router in our path, we can actually ping it directly.
$ ping 216.239.46.212
PING 216.239.46.212 (216.239.46.212) 56(84) bytes of data.
64 bytes from 216.239.46.212: icmp_seq=1 ttl=56 time=26.2 ms
64 bytes from 216.239.46.212: icmp_seq=2 ttl=56 time=24.2 ms
Notice the time is essentially the same as above from the traceroute. This is because our pings have actually traveled the exact same route, we just do not travel the entire path to google.com .
Use Flags For Hop Count, Query, and Wait Times in Traceroute
The wikipedia article for traceroute has an interesting example.
$ traceroute -w 3 -q 1 -m 16 example.com
traceroute to example.com (192.0.32.10), 16 hops max, 60 byte packets
1 spartan.localdomain (192.168.2.1) 0.185 ms
2 70.67.156.1 (70.67.156.1) 7.446 ms
3 rd2cv-ge7-1-0-2.gv.shawcable.net (64.59.162.242) 13.906 ms
4 rc1wt-pos3-0-0.wa.shawcable.net (66.163.77.182) 44.708 ms
5 xe-11-1-0.edge1.Seattle3.Level3.net (4.71.152.49) 67.470 ms
6 ae-31-51.ebr1.Seattle1.Level3.net (4.68.105.30) 17.405 ms
7 4.69.132.49 (4.69.132.49) 36.370 ms
8 ae-34-34.ebr4.SanJose1.Level3.net (4.69.153.34) 43.512 ms
9 ae-5-5.ebr2.SanJose5.Level3.net (4.69.148.141) 38.893 ms
10 ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 46.692 ms
11 ae-62-62.csw1.LosAngeles1.Level3.net (4.69.137.18) 45.929 ms
12 ae-31-80.car1.LosAngeles1.Level3.net (4.69.144.131) 46.317 ms
13 INTERNET-CO.car1.LosAngeles1.Level3.net (4.71.140.222) 103.076 ms
14 www.example.com (192.0.32.10) 102.329 ms
In this example, the -w (wait x seconds) in this case three seconds, the -q (only 1 query instead of 3, note only 1 column for time), and the -m (maximum hop count, so if we were to use traceroute on an IP address in Australia from Canada we might require more than 16 hops). Note also in this example the amount of information that traceroute has garnered. The packet travels Vancouver->Seattle->San Jose->Los Angeles … all this information from a simple traceroute command. This also tells us that most likely there are multiple routers in the same facility as their time difference is essentially the same and their names are almost identical. Look at lines 10,11,12 above:
ae-6-6.ebr2.LosAngeles1.Level3.net (4.69.148.201) 46.692 ms
ae-62-62.csw1.LosAngeles1.Level3.net (4.69.137.18) 45.929 ms
ae-31-80.car1.LosAngeles1.Level3.net (4.69.144.131) 46.317 ms
The main differences between these routers is their prefix with “ebr2 and csw1″ having some meaning. If you were to enter these into Google most likely some interesting information would appear.
How Does Traceroute Function?
By default traceroute uses UDP packets sent to each intermediate device and increments the time-to-live (ttl) of the packet until the UDP reply comes back as a port unreachable.
There are a few flags to note: !H, !N, or !P (host, network or protocol unreachable), !S (source route failed), !F (fragmentation needed), !X (communication administratively prohibited), !V (host precedence violation), !C (precedence cutoff in effect), or ! (ICMP unreachable code ).
Traceroute Protocol Options
Traceroute can now use ICMP, TCP, TCP connection attempt, UDP, and raw packets at the IP layer if you are brave. This is to help alleviate the issue of a firewall getting in the way. A firewall may permit port 80 (http), so you could force traceroute to use TCP at port 80 for your traceroute request.
Comments