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.