There are a number of useful tools that can help you diagnose network problems. We discuss three of them here that are generally helpful; a host of others for diagnosing particular problems are available as well.
The first tool we look at is called ping. ping sends so-called ICMP packets to the server that you specify, the server returns them, and the ping determines the time the round trip took. This is useful to get an idea of the quality of your Internet connection, but we most often use it to see whether we can get a connection somewhere at all. For example, to see whether you have an Internet connection, just ping any computer on the Internet. For example:
kalle@tigger:~> ping www.oreilly.com
PING www.oreilly.com (208.201.239.36) 56(84) bytes of data.
64 bytes from www.oreillynet.com (208.201.239.36): icmp_seq=1 ttl=46 time=280 ms
64 bytes from www.oreillynet.com (208.201.239.36): icmp_seq=2 ttl=46 time=250 ms
64 bytes from www.oreillynet.com (208.201.239.36): icmp_seq=3 ttl=46 time=244 ms
--- www.oreilly.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 244.976/258.624/280.430/15.586 ms
Notice that we pressed Ctrl-C here after a few seconds—it is
not very nice to use the opposite server for this purpose for too
long. What can you see from this? Well, first of all, you can see
that you are actually able to contact a computer on the Internet.
Since you did not type in the numerical IP address, but rather the
hostname, you can also see that DNS name
resolution worked. The first line of the output shows you the IP
address that belonged to www.oreilly.com. In the following lines,
you can see for each packet sent how long the trip to the server and
back took. Of course, the times reported here are going to differ
greatly depending on how far that server is away from you
network-wise. Also notice the icmp_seq
information. Each packet gets a
sequence number, and you should receive all of them back. If you
don’t, if there are gaps in the sequence, then your connection to
that host is flakey, or maybe the host is overloaded and drops
packets.
It should also be said that ping is not completely reliable for diagnosing network problems. Getting no ping response may also be due to the server not responding to the ICMP packets—no server is obliged to do so, and some actually don’t, in order to reduce their server load and in order to increase security (if you cannot really know that somebody is there, it is difficult to attack that somebody). It is considered good networking practice, though, to answer ping requests.
ping is also interesting to see what does
not work. If ping does not answer at all, or
only answers with network not
reachable
or a similar output, you know that you have
issues with your setup. If you know it, try to ping the IP address of your ISP to see
whether the problem is between you and your ISP or further
beyond.[*] If you are using a router that connects your home
network with the Internet, ping the IP address of the router; if
this already does not work, then it is either the setup of your
local computer or the cabling that is faulty. If this works, but you
do not get any further to your ISP, then the reason could be that
you failed to connect with your ISP, for example, because you have
specified the wrong credentials for connecting, or your ISP is down,
or there is a problem with the phone line (your telephone company
might be experiencing problems).
Finally, if specifying the hostname does not work, but you know its IP address (maybe from an earlier attempt), and specifying the hostname works:
kalle@tigger:~/projects/rl5> ping 208.201.239.36 PING 208.201.239.36 (208.201.239.36) 56(84) bytes of data. 64 bytes from 208.201.239.36: icmp_seq=1 ttl=46 time=249 ms --- 208.201.239.36 ping statistics --- 2 packets transmitted, 1 received, 50% packet loss, time 1001ms rtt min/avg/max/mdev = 249.698/249.698/249.698/0.000 ms
then you know that you have a problem with DNS name resolution and can continue to look further in that area.
The traceroute command goes a step further than ping. It not only shows you whether you can reach a host on the Internet (or in your own network), but also which route the packets take on their way to get there. That can be useful to diagnose problems that are beyond your reach, such as with central routers on the Internet—not that you could do much about that, but then at least you know that you do not need to debug your own setup.
Here is an example of using traceroute.
Notice that here we specify the full path to the command. It is
usually in a directory that only root has in
its PATH
.
traceroute can be executed just fine as a
normal user, however).
kalle@officespace:~> /usr/sbin/traceroute www.oreilly.com
traceroute to www.oreilly.com (208.201.239.36), 30 hops max, 40 byte packets
1 81.169.166.1 0.204 ms 0.174 ms 0.174 ms
2 81.169.160.157 0.247 ms 0.196 ms 0.195 ms
3 81.169.160.37 0.351 ms 0.263 ms 0.320 ms
4 PC1.bln2-g.mcbone.net (194.97.172.145) 0.256 ms 0.273 ms 0.217 ms
5 L0.bln2-g2.mcbone.net (62.104.191.140) 0.417 ms 0.315 ms 0.272 ms
6 lo0-0.hnv2-j2.mcbone.net (62.104.191.206) 4.092 ms 4.109 ms 4.048 ms
7 lo0-0.hnv2-j.mcbone.net (62.104.191.205) 4.145 ms 4.184 ms 4.266 ms
8 L0.dus1-g.mcbone.net (62.104.191.141) 8.206 ms 8.044 ms 8.015 ms
9 c00.ny2.g6-0.wvfiber.net (198.32.160.137) 92.477 ms 92.522 ms 92.488 ms
10 b0-00.nyc.pos1-35-1.wvfiber.net (63.223.28.9) 166.932 ms 167.323 ms 166.356
ms
11 b00.chi.pos1-6-1.wvfiber.net (63.223.0.214) 167.921 ms 166.610 ms 166.735 ms
12 63.223.20.53 166.543 ms 166.773 ms 166.429 ms
13 unknown63223030025.wvfiber.net (63.223.30.25) 166.182 ms 165.941 ms 166.042
ms
14 unknown63223030022.wvfiber.net (63.223.30.22) 165.873 ms 165.918 ms 165.919
ms
15 unknown63223030134.wvfiber.net (63.223.30.134) 165.909 ms 165.919 ms 165.832
ms
16 ge7-br02-200p-sfo.unitedlayer.com (209.237.224.17) 165.987 ms 165.881 ms
166.022 ms
17 pos-demarc.sf.sonic.net (209.237.229.26) 168.849 ms 168.753 ms 168.986 ms
18 0.at-0-0-0.gw4.200p-sf.sonic.net (64.142.0.182) 169.628 ms 0.at-1-0-0.
gw4.200p-sf.sonic.net (64.142.0.186) 169.632 ms 169.605 ms
19 0.ge-0-1-0.gw.sr.sonic.net (64.142.0.197) 173.582 ms 173.877 ms 174.144 ms
20 gig49.dist1-1.sr.sonic.net (209.204.191.30) 176.822 ms 177.680 ms 178.777 ms
21 www.oreillynet.com (208.201.239.36) 173.932 ms 174.439 ms 173.326 ms
Here, the trace was successful, and you can also see how much
time the packets took from hop to hop. With some geographical
knowledge and some fantasy, you can guess the route along which the
packets went. For example, the computer on which this command was
executed was located in Berlin, Germany,[*] so it stands to reason that bln2
in lines 4 and 5 is some host in
Berlin that belongs to the ISP somehow. Looking
at a map of Germany, you might be able to guess that hops 6 and 7
went via Hanover, and hop 8 was in Düsseldorf. That’s apparently
also where the cable across the big pond starts, because hops 9 and
10 were quite likely in New York City. 11 seems to be Chicago, and
16 to 18 could be San Francisco. That makes sense, given that
O’Reilly’s headquarters (and therefore the likely location of the
machine www.oreilly.com/www.oreillynet.com) is in
California.
dig is the last diagnostic utility we cover in this section. dig is a utility that queries DNS servers and returns the information held about a particular domain. Let’s start with an example right away:
kalle@tigger:~> dig oreilly.com
; <<>> DiG 9.3.1 <<>> oreilly.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52820
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 0
;; QUESTION SECTION:
;oreilly.com. IN A
;; ANSWER SECTION:
oreilly.com. 21600 IN A 208.201.239.36
oreilly.com. 21600 IN A 208.201.239.37
;; AUTHORITY SECTION:
oreilly.com. 21600 IN NS ns2.sonic.net.
oreilly.com. 21600 IN NS ns.oreilly.com.
oreilly.com. 21600 IN NS ns1.sonic.net.
;; Query time: 252 msec
;; SERVER: 195.67.199.9#53(195.67.199.9)
;; WHEN: Wed Jul 6 13:31:02 2005
;; MSG SIZE rcvd: 123
Now what does this tell you? Have a look at the ANSWER SECTION
. It tells you the IP
addresses in use by the domain name service serving the domain
oreilly.com. If you have a problem resolving
addresses in this domain, you could try to ping these addresses to
see whether the problem is actually with O’Reilly’s
DNS and not your own. The AUTHORITY SECTION
gives you information
about the so-called authoritative nameservers for this domain—the
ones that are supposed to always give you the correct answer. It is
good network administration practice to have at least two, and
preferably three, of them, and to have them in different networks,
so that the DNS service still works when one of
them is down.
The third line from the bottom tells you the nameserver that was used to perform the DNS query; this is taken from your own setup. You can use this information to see whether you have entered the correct information in your DNS setup.
You can also specify a particular nameserver to query. For example, if you wanted to use the nameserver running at 195.67.199.10 instead, you could use:
dig @195.67.199.10 oreilly.com
Normally, you should get exactly the same result, but if you get a result at all from one of them but not from the other, then it’s likely that the one not responding is simply down, or, per your network configuration, not reachable.