Basic Steps to Troubleshooting TCP/IP

By Ronald Nutter MCSE/MCNE

Published in TechRepublic's Windows Support Professional

It's becoming increasingly common to have TCP/IP present on networks. Just a few years ago, it was almost the exception to the rule. For those who haven't dealt much with TCP/IP, troubleshooting can be a challenge. This article will give you the basic steps to at least identify the point of failure, if not the cause of the problem.

On This Page

Link basics
Start at the beginning
Watch out for application problems
Getting a little extra help
Conclusion

Link basics

A link created from one system to another in TCP/IP is a series of connections joined by routers. Each router or change in the path is referred to as a hop. Determining where a communication path fails is like building a wall using blocks—one block leads to the next one until you reach the end. The ping command, although a very simple utility, can show you very quickly what condition the path to the host is in. If you get responses from every link in the connection, you're then looking at some type of service problem at the host you're trying to access.

Start at the beginning

The first step I normally take when a user complains about not being able to access a particular host (or any hosts at all) is to see that TCP/IP is correctly set up on his or her system. I begin this trek by opening a DOS window on the system (this applies to both Windows 9x and NT) and using the ping command to check the IP address 127.0.0.1. To do so, type the following at the DOS prompt:

PING 127.0.0.1

If TCP/IP has been correctly installed (notice I said "installed," and not "configured"), you should get a response similar to that shown in Figure A. 127.0.0.1 is also referred to as the loopback address; it's a reserved address for just this purpose in TCP/IP troubleshooting.

Figure A: This response tells you that TCP/IP has been installed on the workstation in question.

If you get a response other than that shown in Figure A, you should next check that TCP/IP has been installed and has been bound to the adapter. You can do this by right-clicking on Network Neighborhood and choosing Properties from the shortcut menu. In Windows 9x, you should see an entry for the network card (either a standard network card or a dial-up adapter, depending on the type of connection you're working with) and a protocol showing binding to the network card you're using. The binding to a specific network card may not appear if you have only one network card and aren't using a dial-up adapter.

In Windows NT, you'll need to click two different places to get the information. Click the Protocols tab to verify that TCP/IP has been installed and click the Adapters tab to verify that a network card is installed. Unlike with Windows 95, if you're only using a dial-up adapter for your Internet connection, you may not see an entry in the Adapters tab.

The default gateway acts as a traffic cop for segments in TCP/IP. When a workstation sees that an address it's trying to contact isn't on its local segment, it hands off the traffic to the default gateway, which will either know on what segment the destination host can be found or will forward the traffic to its default gateway. The subnet mask can be used in more advanced TCP/IP implementations to allow more than one segment to use parts of an IP address that's been assigned to a company by an ISP or other service provider.

While you're looking in the Properties tab of Network Neighborhood, make note of the IP address, subnet mask, and default gateway, as well as the IP addresses of the Domain Name Server (DNS) systems the workstation is configured to use. You can confirm that the information is seen by the workstation correctly by using the IPCONFIG /ALL command for NT systems and WINIPCFG on Windows 9x systems. If you prefer a graphical program to use on NT (similar to that available in Win9x), purchase a copy of the NT Resource Kit.

The next address to ping is the workstation itself. Although you've already pinged the workstation by using the loopback address 127.0.0.1, this step only verified that TCP/IP was functional—not the extent to which it's configured. By pinging the card using its assigned IP address, you're now confirming that IP has been configured on the workstation. Until you ping a few other places on the network, you won't know whether the configuration is correct.

Using the ping command, check for response from the IP address listed for this workstation to use as the default gateway. If you get response from the default gateway, it's a good idea to ping one or more systems on the same segment where the workstation you're testing resides. Although you've pretty much confirmed at this point that TCP/IP seems to be up and running, testing communication for devices on the local segment verifies that communication exists with devices other than the default gateway. Doing so checks that the subnet mask is the same for all devices that have been tested so far.

Working on the basis that you've received a response from every ping command you've tried so far, only a step or two remains. Try pinging one or two devices on the other side of the router that's serving as your default gateway. Doing so confirms that you're using the correct default gateway and that the default gateway knows how to find the address you're looking for.

Watch out for application problems

Keep in mind that pinging a host doesn't mean you can reach it with an application program. For example, a customer recently came to me saying that he was unable to access his AS/400 using IBM's Client Access program. By using the ping command to check the communication path from the workstation having the problem to the target AS/400, I was able to verify that the communication path was good.

As a final step, I used the Telnet program included with both Windows 95 and 98 and was able to get a sign-on screen that the IBM Client Access program was unable to provide. This result proved that the path to the AS/400 was sound and the problem was related either to a service on the AS/400 or to a configuration change to the IBM Client Access program. After a little investigative work, I learned that the version of the AS/400 operating system the customer was using had a known problem handling TCP/IP communications. The problem was solved via an upgrade to a newer release of the operating system.

Getting a little extra help

There are times that using just the basic ping command doesn't really tell you where the problem is. Although you can use the tracert command to indicate the path you're following to the destination host, the information it presents can be a little cryptic at best. Fortunately, I recently came across a nice little utility called NEOTRACE that can help you identify the route your traffic is taking to get to the destination. Figure B shows it in action. (For more information on NEOTRACE, go to https://www.neotrace.com. )

Figure B: NEOTRACE—a graphical version of tracert—presents the path to the host you're trying to reach in a format that's easy to understand.

For example, I recently had to document a customer's network, which had grown faster than the company's documentation could keep up. In a little over an hour I was able to document how the network was set up and the paths used to reach the more commonly used hosts. The result appeared in a manner that less technically savvy individuals could understand without requiring a detailed knowledge of TCP/IP.

Conclusion

When you encounter a TCP/IP communication problem, get a clear definition of the exact problem the problem the user is having. Then, check the path from workstation to host one step at a time. You'll find that this process makes locating the source of the problem easier, and you'll be able to fix the problem more quickly. Tackling the problem one step at a time will help minimize the stress in the situation, for both you and the user.

Ronald Nutter is a senior systems engineer in Lexington, Kentucky. He's an MCSE, Novell Master CNE, and Compaq ASE. Ron has worked with networks ranging in size from single servers to multiserver/multi-OS setups, including NetWare, Windows NT, AS/400, 3090, and UNIX. He's also the Help Desk Editor for Network World. You can reach Ron at Rnutter@ix.netcom.com.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.