|
||
|
||
Traceroute is a network tool that helps determine the path packets take as they travel from one location to another, identifying all of the “hops” along the way. I wonder why they are called hops*? Almost all operating systems have traceroute utilities built in. The command is just that “traceroute”, Windows systems abbreviate the command as “tracert” to deal with the 8.3 file naming convention of old.
(*Hops—because packets are frogs?—Hop is the term used when a packet is relayed to the next stop along the path to its destination. I.e.—the packet lands and then bounces, or is bounced, to its next stop. You should think of hops as relay points. Each, hop or relay point is really a router that determines how to best direct that packet to the next relay point so that it can get to its final destination. If you think of the concept of a relay race you have it. Each point in the race tells you how to get to the next point.)
So, let’s look at what information traceroute gives you. Following is a traceroute from my desktop computer, running Windows Vista, to www.cern.net.
C:\>tracert www.cern.net<br /><br />
Tracing route to www.cern.net [66.116.125.235]<br />
over a maximum of 30 hops:<br /><br />
1 <1 ms <1 ms <1 ms dnsstuff-gw.customer.alter.net [207.204.91.75]<br />
2 178 ms 175 ms 146 ms 354.ATM0-0.GW12.BOS4.ALTER.NET [207.204.91.79]<br />
3 98 ms 77 ms 103 ms 0.so-3-3-0.XL1.BOS4.ALTER.NET [152.63.22.114]<br />
4 184 ms 166 ms 173 ms 0.so-6-0-0.XL3.NYC4.ALTER.NET [152.63.16.221]<br />
5 117 ms 135 ms 148 ms 0.ge-6-0-0.BR3.NYC4.ALTER.NET [152.63.18.5]<br />
6 178 ms 166 ms 191 ms te-3-2.car4.NewYork1.Level3.net [4.68.110.233]<br />
7 101 ms 107 ms 118 ms vlan99.csw4.NewYork1.Level3.net [4.68.16.254]<br />
8 149 ms 155 ms 158 ms ae-92-92.ebr2.NewYork1.Level3.net [4.69.134.93]<br />
9 133 ms 98 ms 127 ms ae-2.ebr1.Chicago1.Level3.net [4.69.132.65]<br />
10 204 ms 198 ms 206 ms ae-68.ebr3.Chicago1.Level3.net [4.69.134.58]<br />
11 216 ms 218 ms 223 ms ae-3.ebr2.Denver1.Level3.net [4.69.132.61]<br />
12 116 ms 134 ms 113 ms ae-1-100.ebr1.Denver1.Level3.net [4.69.132.37]<br />
13 194 ms 187 ms 193 ms ae-5-5.car2.SaltLakeCity1.Level3.net [4.69.133.125]<br />
14 198 ms 158 ms 181 ms ae-11-11.car1.SaltLakeCity1.Level3.net [4.69.133.121]<br />
15 241 ms 225 ms 216 ms ae-2-2.car2.LasVegas1.Level3.net [4.69.133.117]<br />
16 129 ms 200 ms 186 ms ae-11-11.car1.LasVegas1.Level3.net [4.69.133.113]<br />
17 192 ms 212 ms 233 ms SWITCH-COMM.car1.LasVegas1.Level3.net [4.71.176.6]<br />
18 238 ms 272 ms 194 ms gig2-2.esw03.las.switchcommgroup.com [66.209.64.238]<br />
19 105 ms 137 ms 106 ms gig5-1.esw09.las.switchcommgroup.com [66.209.64.194]<br />
20 170 ms 187 ms 198 ms cust-66.209.87.100.switchcommgroup.com [66.209.87.100]<br />
21 201 ms 123 ms 170 ms mdnh-41.las.marchex.com [66.116.125.235]<br />
Trace complete.<br />
C:\><br />
Following is a traceroute to the same location, www.cern.net, from my desktop using CentOS5:
[root@localhost ~]# tracert www.cern.net<br />
traceroute to www.cern.net (66.116.125.235), 30 hops max, 40 byte packets<br />
1 dnsstuff-gw.customer.alter.net (208.214.96.90) 6.699 ms 5.841 ms 5.260 ms<br />
2 354.atm0-0.gw12.bos4.alter.net (208.214.96.89) 185.911 ms 186.248 ms 186.157 ms<br />
3 0.so-3-3-0.xl1.bos4.alter.net (152.63.22.114) 215.028 ms 188.123 ms 188.947 ms<br />
4 0.so-6-0-0.xl3.nyc4.alter.net (152.63.16.221) 189.572 ms 191.120 ms 191.114 ms<br />
5 0.ge-6-0-0.br3.nyc4.alter.net (152.63.18.5) 191.599 ms 193.061 ms 193.003 ms<br />
6 te-3-2.car4.newyork1.level3.net (4.68.110.233) 193.721 ms 204.217 ms 205.645 ms<br />
7 vlan99.csw4.newyork1.level3.net (4.68.16.254) 206.365 ms 183.727 ms 184.975 ms<br />
8 ae-92-92.ebr2.newyork1.level3.net (4.69.134.93) 184.742 ms 185.032 ms 187.111 ms<br />
9 ae-2.ebr1.chicago1.level3.net (4.69.132.65) 229.058 ms 230.349 ms 227.796 ms<br />
10 ae-68.ebr3.chicago1.level3.net (4.69.134.58) 224.952 ms 225.504 ms 225.489 ms<br />
11 ae-3.ebr2.denver1.level3.net (4.69.132.61) 228.683 ms 215.074 ms 213.857 ms<br />
12 ae-1-100.ebr1.denver1.level3.net (4.69.132.37) 213.081 ms 205.530 ms 183.056 ms<br />
13 ae-5-5.car2.saltlakecity1.level3.net (4.69.133.125) 199.908 ms 199.252 ms 199.830 ms<br />
14 ae-11-11.car1.saltlakecity1.level3.net (4.69.133.121) 200.940 ms 171.107 ms 169.143 ms<br />
15 ae-2-2.car2.lasvegas1.level3.net (4.69.133.117) 169.689 ms 169.640 ms 169.623 ms<br />
16 ae-11-11.car1.lasvegas1.level3.net (4.69.133.113) 167.968 ms 167.730 ms 188.150 ms<br />
17 switch-comm.car1.lasvegas1.level3.net (4.71.176.6) 188.125 ms 186.983 ms 186.957 ms<br />
18 gig2-2.esw03.las.switchcommgroup.com (66.209.64.238) 136.599 ms 121.965 ms 121.339 ms<br />
19 gig5-1.esw09.las.switchcommgroup.com (66.209.64.194) 121.180 ms 119.459 ms 147.879 ms<br />
20 cust-66.209.87.100.switchcommgroup.com (66.209.87.100) 147.805 ms 146.635 ms 145.933 ms<br />
21 mdnh-41.las.marchex.com (66.116.125.235) 145.718 ms 145.113 ms 145.951 ms<br />
[root@localhost ~]#
When you take a look at these they look remarkably similar, aside from some apparent formatting issues. However, there is one significant difference. When Windows does a traceroute it uses ICMP packets. When Linux does it traceroute it uses UDP packets (by default). As you can see from the help below, there are quite a few options for the Linux version of traceroute as compared with the help from Windows.
How do I read a traceroute?
The above examples show each hop, or point along the path to the destination. The name of the host at the IP address for that hop and three columns of times, specifically round trip times (RTT). The round trip time is the amount of time it took for the packet to get from your machine to the hop and then come back. Typically traceroute sends three packets and reports the RTT for each. If the packet does not come back within a timeout period an asterisk (*) is displayed.
Frequently you will see three asterisks, this indicates, as you might expect that the packet never made it back to the machine initiating the traceroute. This should not be alarming as many hosts are set to not respond to one or another packet types. If the hops continue past this point and ultimately reaches the destination then that is the case, a hop is not responding to your traceroute. If you end with no information, only asterisks, and never reach the destination, then it is a good bet that there is an issue with something after the last hop with data.
How DNSstuff does traceroute
The traceroute we offer is the unification of many steps you could do yourself, if you wanted to take the time and energy. First and sometimes most importantly our traceroutes originate from our datacenters. Many times you are faced with the dilemma, I can get to the site but someone else can’t from where they are. Using our traceroute allows you to test from another location; one that you know should work reliably. But we throw in a whole lot more information just to make your life easier. For example we traceroute with ICMP (T1 column), TCP (T2 column) and UDP (T3 column), each with their own time in milliseconds, we then give you the best time and the incremental time added by that hop. A nice graph of each hop is displayed. We look up the Assigned System Number and Assigned System Name as ARIN understands it, the hostname if it exists, the TTL, the country and report, if we can determine it, the system type and finally the time that that hop thinks it is. Basically this is everything you could ever hope to want in a traceroute tool, easily accessible via a simple web browser or even your WAP enabled phone!
As an aside, many people may think that we simply call an operating system function to perform the work of our tools. We don’t. We actually form every bit that goes on the wire in real-time. We then analyze each bit, byte and packet as they come back. Our system is really an advanced network sniffer with a large expert system woven in that understands many of the idiosyncrasies and bugs of DNS and networking. So it’s true this is not your father’s traceroute tool!
Hey—so what is next for Traceroute?
Enter VectorTrace. We are putting the finishing touches on a new product called VectorTrace. VectorTrace is unique in that it allows for traceroutes to be performed simultaneously from multiple locations and that information displayed in context of each other. For example, on initial launch of VectorTrace will trace from three discrete locations and display the route taken to the requested destination. This will allow the user to understand critical common points in the path. This will help identify the most critical points with poor performance so that you can remedy that situation by working with the administrators of that point or giving you the information to choose a better location for the final destination. As the product matures we will offer options to present the data on a map and even automate and alert on the quality of the paths taken.
Traceroute to www.cern.net
Number of hops: 17
Last hop responding to ICMP: 17, UDP: 17, TCP: 17.
I did not detect any firewalls that are blocking ICMP, unwanted UDP, or unwanted TCP packets.
Legend:
• ECN was used on the TCP packets.
• T1/T2/T3 are the round-trip times in milliseconds (1/1000ths of a second).
• T1 uses a proper ICMP-based tracert (Microsoft style). T2 uses a UDP-based traceroute (Unix-style). T3 uses a TCP-based traceroute (port 80).
• Since many ISPs now block ICMP and/or packets to unknown ports, T3 (rarely used by traceroute programs) typically shows the best results.
• Best times may be theoretical (if it takes 80ms to hop 10, and 50ms to hop 11, we say the best time for hop 10 is 50ms).
• If no reverse DNS entry is given for an IP, we display ‘unknown.example.com’ if the domain name is known.
CentOS5 (Linux) Help:
[root@localhost ~]# traceroute—help Usage: traceroute [ -46dFITUnrAV ] [ -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 Set DF (don’t fragment bit) on -f first_ttl —first=first_ttl Start from the first_ttl hop (instead from 1) -g gate,... —gateway=gate,... Route packets throw 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 -U —udp Use UDP datagram (default) 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 squeries —sim-queries=squeries Set the number of probes to be tried simultaneously (default is 16) -n Do not resolve IP addresses to their domain names -p port —port=port Use destination port port. It is an initial value for the UDP destination port (incremented by each probe, default is 33434), for the ICMP seq number (incremented as well, default from 1), and the constant destination port for TCP tries (default is 80) -t tos —tos=tos Set the TOS (IPv4 type of service) or TC (IPv6 traffic class) value for outgoing packets -l flow_label —flowlabel=flow_label Use specified flow_label for IPv6 packets -w waittime —wait=waittime Set the number of seconds to wait for response to a probe (default is 5.0). Non-integer (float point) values allowed too -q nqueries —queries=nqueries Set the number of probes per each hop. Default is 3 -r Bypass the normal routing and send directly to a host on an attached network -s src_addr —source=src_addr Use source src_addr for outgoing packets -z sendwait —sendwait=sendwait Minimal time interval between probes (default 0). If the value is more than 10, then it specifies a number in milliseconds, else it is a number of seconds (float point values allowed too) -A —as-path-lookups Perform AS path lookups in routing registries and print results directly after the corresponding addresses -V —version Print version info and exit —help Read this help and exit
Arguments: + host The host to traceroute to packetlen Specify an alternate probe packet length (default is 40). Useless for TCP SYN
Windows Help: C:\>tracert /?
Usage: tracert [-d] [-h maximum_hops] [-j host-list] [-w timeout] [-R] [-S srcaddr] [-4] [-6] 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 (IPv4-only). -w timeout Wait timeout milliseconds for each reply. -R Trace round-trip path (IPv6-only). -S srcaddr Source address to use (IPv6-only). -4 Force using IPv4. -6 Force using IPv6.
Sponsored byCSC
Sponsored byWhoisXML API
Sponsored byRadix
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byVerisign
Sponsored byDNIB.com
A World-Renowned Source for Internet Developments. Serving Since 2002.