5.3 Network Testing and Troubleshooting | Essential System Administration, Third Edition

Oncenetwork configuration is complete, you will need to test network connectivity and address any problems that may arise. Here is an example testing scheme:

Verify that the network hardware is working by examining any status lights on the adapter and switch or hub.
Check basicnetwork connectivity using the ping command. Be sure to use IP addresses instead of hostnames so you are not dependent on DNS.
Test name resolution using ping with hostnames or nslookup (see Section 8.1).
Check routing by pinging hosts beyond the local subnet (but inside the firewall).
Test higher-level protocol connectivity by using telnet to a remote host. If this fails, be sure that inetd is running, that the telnet daemon is enabled, and that the remote host from which you are attempting to connect is allowed to do so (inetd is discussed in Chapter 8).
If appropriate, verify that other protocols are working. For example, use a browser to test the web server and/or proxy setup. If there are problems, verify that the browser itself is configured properly by attempting to view a local page.
Test any network servers that are present on the local system (see Chapter 8).

The first step is to test the network setup and connection with the ping command. ping is a simple utility that will tell you whether the connection is working and the basic setup is correct. It takes a remote hostname or IP address as its argument:^[21]

^[21] Control-C terminates the command. Entering Control-T while it is running displays intermediate status information.

$ ping hamlet  PING hamlet: 56 data bytes  64 bytes from 192.0.9.3: icmp_seq=0. time=0. ms  64 bytes from 192.0.9.3: icmp_seq=1. time=0. ms  64 bytes from 192.0.9.3: icmp_seq=4. time=0. ms ...  ^C ----hamlet PING Statistics----  8 packets transmitted, 8 packets received, 0% packet loss  round-trip (ms)  min/avg/max = 0/0/0

From this output, it is obvious that hamlet is receiving the data sent by the local system, and the local system is receiving the data hamlet sends. On Solaris systems, ping's output is much simpler, but still answers the same central question: "Is the network working?":

$ ping duncan  duncan is alive

Use the -s option if you want more detailed output.

Begin by pinging a system in the local subnet. If this succeeds, try testing the network routes by pinging systems that should be reachable via defined gateways.

If pinging any remote system inside the firewall fails,^[22] try pinging localhost and then the system's own IP address. If these fail also, check the output of ifconfig again to see if the interface has been configured correctly. If so, there may be a problem with the network adapter.

^[22] If you need to check connectivity beyond the firewall, you need to use the ssh facility or some other higher-level protocol that is not blocked (e.g., http).

On the other hand, if pinging the local system succeeds, the problem lies either with the route to the remote host or in hardware beyond the local system. Check the routing tables for the former (make sure there is a route to the local subnet), and check the status lights at the hub or switch for the latter. If hardware appears to be the problem, try swapping the network cable. This will either fix the problem or suggest that it lies with the connecting device or port within that device.

Once basic connectivity has been verified, continue testing by moving up the protocol stack, as outlined above.

Another utility that is occasionally useful for network troubleshooting is arp. This command displays and modifies IP-to-MAC address translation tables. Here is an example using its -a option, which displays all entries within the table:

# arp -a mozart (192.168.9.99) at 00:00:F8:71:70:0C [ether] on eth0 bagel (192.168.9.75) at 00:40:95:9A:11:18 [ether] on eth0 lovelace (192.168.9.143) at 00:01:02:ED:FC:91 [ether] on eth0 sharon (192.168.9.4) at 00:50:04:0A:38:00 [ether] on eth0 acrasia (192.168.9.27) at 00:03:BA:0D:A7:EC [ether] on eth0 venus (192.168.9.35) at 00:D0:B7:88:53:8D [ether] on eth0

I found arp very useful for diagnosing a duplicate IP address that had been inadvertently assigned. The symptom of the problem was that a new printer worked only intermittently and often experienced long delays when jobs attempted to connect to it. After checking the printer and its configuration several times, it finally occurred to me to check arp. The output revealed another host with the IP address the printer was using. Once the printer's IP address was changed to a unique value, everything was fine.

arp also supports an -n option which bypasses name resolution and displays only IP addresses in the output. This can again be useful when there are DNS problems.

Once networking is configured and working, your next task is to monitor its activity and performance on an ongoing basis. These topics are covered in detail in Section 8.6 and Section 15.7, respectively.