Section 13.6. Network Diagnostics Tools
13.6. Network Diagnostics ToolsThere 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. 13.6.1. pingThe 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 secondsit 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 packetsno 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. 13.6.2. tracerouteThe 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 Internetnot 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.
13.6.3. digdig 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 domainthe 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. |
EAN: 2147483647
Pages: 220