Oncenetwork configuration is complete, you will need to test network connectivity and address any problems that may arise. Here is an example testing scheme:
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:
$ ping hamlet PING hamlet: 56 data bytes 64 bytes from 188.8.131.52: icmp_seq=0. time=0. ms 64 bytes from 184.108.40.206: icmp_seq=1. time=0. ms 64 bytes from 220.127.116.11: 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, 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.
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.