Troubleshoot network errors: TCP/IP Checklist
Whether your systems are powered by Windows or Linux, network configuration problems inevitably arise. Often the problem can be traced to an improperly configured TCP/IP setting, but finding the culprit can be difficult. You can use the following checklist to help you identify and eliminate network TCP/IP errors.
1. What stopped working? The client or the server? Ask around before attacking coworkers� PCs; learn if the outage is affecting others or just a single desktop.
2. If the server stopped working, you should notice many office mates banging their heads against their desks simultaneously. If this is the case, focus on fixing the server.
3. If a single client PC has stopped responding to the network, ask the user whether new software was just loaded or any recent changes have been made to the system, including the installation of service packs, new Internet software, Elf Bowling games, and so on.
4. Check the physical network. The physical topology of your network is most prone to failure. In fact, most network problems are often due to Physical Layer failures.
5. Is it plugged in? Check all network cable connections. Start at the NIC; is there a green light? Check the wiring closet to see if someone "borrowed" the patch cable. Check the hub to see if the system is getting a link across the cable.
6. If you don�t have a cable tester, get one. Cabling is very susceptible to electricians, cleaning people, HVAC personnel, and so on.
7. Start PINGing. Both Windows and
Linux have the ping command. In a typical network you have this order
(client->gateway->server) or (client->gateway->internet). First, attempt
to PING yourself from the Windows command prompt or use the Linux shell.
Your local "loopback" address for such testing is 127.0.0.1. Windows
users should see the response shown in Listing A, while Linux operators
should see the results shown in Listing B.
Listing A: Windows
| C:\WINDOWS>ping
127.0.0.1 pinging 127.0.0.1 with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<10ms TTL=32 Reply from 127.0.0.1: bytes=32 time<10ms TTL=32 Reply from 127.0.0.1: bytes=32 time<10ms TTL=32 Reply from 127.0.0.1: bytes=32 time=1ms TTL=32 ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 1ms, Average = 0ms |
Listing B: Linux
| [root@gateway /root]# ping -c 4 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=1.2 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.9 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.9 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=255 time=0.9 ms --- 127.0.0.1 PING statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.9/0.9/1.2 ms |
Note that in Linux you must add -c 4 to the command, which requests four PINGs. Otherwise, you must stop the test using [CTRL]C.
8. If you do not receive a successful PING from yourself, in Windows, try re-installing the TCP/IP protocol from the Network Control Panel. In Linux, see if your Ethernet card is loading properly by using ipconfig. It should provide the information shown in Listing C.
Listing C
[root@gateway /root]# ifconfig
|
By issuing the interface configuration (ifconfig) program, you will receive a list of your interfaces. If the loopback (lo) is not listed, you may have an incorrectly configured kernel or possible problems with the loopback module. Try recompiling/reinstalling to see if that resolves the problem.
9. If PINGing your loopback worked fine, then try PINGing someone who is on the same subnet as you. In the ifconfig example above, the IP address is set to 192.168.1.100. Thus, in this scenario you should attempt to ping 192.168.1.1. Be sure the target IP address being PINGed is a valid IP address assigned to a system; otherwise, you�ll receive errors.
Use the Start | Run | ipconfig command to learn your NT machine's IP configuration (use WINIPCFG with Windows 98). ipconfig provides valuable information about what network you are on, as well as your gateway address. In Linux, use ifconfig to learn your network settings.
10. If you can PING someone on your local subnet, move on to the next step. If you can't, you're probably experiencing a Physical Layer failure. The usual suspects are bad cables or a NIC gone bad (they do that sometimes). With loopback, you were just testing the inner workings of the TCP/IP protocol stack; with PINGing on your local subnet you tested for failure on the failing machine. Try replacing the network card and using a new patch cable.
11. The next problem area is in the gateway. Find the IP address of your gateway. You can find this in the ipconfig screen with NT systems (WINIPCFG for Windows 98) or in Linux by running the netstat -rn command, providing these results:
| [root@gateway /root]# netstat -rn Kernel IP routing table
|
The -rn prints the routing table and puts everything in numeric format. In this example, the default gateway (0.0.0.0) is 192.168.1.254. If you don't have a gateway configured, then one will not show up in WINIPCFG or when using netstat. This is a problem.
In Windows, locate Start | Settings | ControlPanel | Network | TCP/IP | Gateway and add your gateway. This is your local interface on your router. In Linux, use linuxconf or set up a temporary route using the route add command.
PING this address; this will prove a solid connection from your PC to the gateway. If you have made it this far, the PC is working, the cabling is working, and the router (gateway) interface is working. You can skip to the next section.
However, if you receive no response from the gateway, and you have one configured, it's time to call in the big guns. Your router is improperly configured. It must have a local interface (IP address) on your subnet to listen to the traffic on your network. If there is no interface, have the router administrator add one. If it has one but has stopped working, it could mean you�re experiencing a router failure, and others will be affected as well. Conversely, the router administrator may have loaded an old config; check with the administrator to make sure this isn't the case.
12. The final step is through the gateway. PING something that is on the other side of the gateway. In an intranet, PING a printer on a remote subnet. On the Internet, PING www.jrksoftware.com (for example). If you do so successfully, you should not have a problem. If you can't get to a particular system in your network or on the Internet, that resource may not be available. You may want to tell the administrators of those systems about this checklist! Certainly, you can expect they�re working through the same difficulties as you.
Remember, always look for the most obvious problems first, and if in doubt, reboot your system.
