When you troubleshoot Windows network connectivity, make sure there are no problems with the local TCP/IP protocol stack. This tip, originally posted on WindowsNetworking.com, guides you step-by-step through testing the local host's ability to contact the DNS server and the default gateway server and how to test host name resolution.
In a previous article, I showed you how to determine which IP address your system is using as its primary address. The next step in the process is to verify that the IP address configuration is working correctly, and that there are no problems with the local TCP/IP protocol stack.
First, you need to ping the local host address. There are a couple of different ways of accomplishing this. One way is to enter the following command:
PING LOCALHOST
When you enter this command, Windows will ping the address 127.0.0.1. Regardless of your machine's IP address, Windows will always use 127.0.0.1 as the local host address. Therefore, an alternative to the command listed above is to simply enter the following command:
Ping 127.0.0.1
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
Upon entering this command, you should see a successful ping, just as you would with any other ping command. You can see an example of this, shown in Figure A.
Figure A: Receiving a successful ping when attempting to ping the local host address
Pinging the local host address does nothing to diagnose communication problems with a remote host. It does however allow you to confirm that your local TCP/IP stack is functioning correctly. If you ping the local host address and receive a destination host unreachable error message, it is almost always an indication that TCP/IP is configured incorrectly, or that some part of the local TCP/IP stack is damaged.
It has been my experience that you can usually get around this problem by removing the TCP/IP protocol from the computer, and then reintroducing it from scratch.
Ping the default gateway
In the previous part of this article series, I mentioned that there were several different aspects of the TCP/IP configuration that you needed to document, and have on hand for the troubleshooting process. Among these pieces of information are the IP addresses of the default gateway and of the primary DNS server.
Assuming that the hosts that you're trying to communicate with is on a remote network, or on a different segment of your corporate network, then the next thing that you need to attempt is to ping the default gateway. You can accomplish this by simply appending the default gateway's IP address to the ping command. For example, if you look at Figure B, you will notice that my TCP/IP configuration lists my default gateway address as 147.100.100.100. I then simply pinged this address. This verifies that the local machine can communicate with the default gateway. It also tells you that communications on the local network are working as intended, at least at the IP address level.
Figure B: Default gateway ping verifying that IP packets can reach your network's default gateway
Ping the DNS server
So far we have established that IP level communications are working between the local computer and the default gateway. This does not however guarantee that host names are being resolved to IP addresses. In the first part of the article series, Using ping command to troubleshoot network connectivity, I showed you how you could use the destination host's fully qualified domain name in conjunction with the ping command as a way of verifying that the DNS server is doing its job. There are a couple of other ways that you can easily test DNS name resolution though.
One thing that you can do is ping the DNS server's IP address, as shown in Figure C. This does not guarantee the name resolution is working correctly, but it does verify that the local machine is able to communicate with the DNS server.
Figure C: Verify that the host can communicate with your DNS server
Another option is to use the Nslookup command to verify that name resolution is working properly. To do so, simply enter the Nslookup command, followed by the remote host's fully qualified domain name. The Nslookup command should be able to resolve the fully qualified domain name to an IP address, as shown in Figure D.
Figure D: The Nslookup command showing whether or not your DNS server can resolve the host name
The image above can be a bit misleading at first, if you are not used to working with Nslookup. Initially, this screen appears to be reporting an error. If you take a closer look though, you can see that the first part of the information that has been returned refers to the local DNS server. You can tell this because the IP address that is referenced matches the DNS server's IP address. However, the lower section of the returned information provides you with the IP address of the host that you have queried. As long as this IP address is listed, then the DNS query was successful.
If the name resolution process fails, then there is a DNS problem. The actual problem may be any one of a number of different problems with the DNS server. For example, the DNS servers forwarding address may not be correct, or the DNS server may not have access to the Internet, which it needs in order to contact higher level DNS servers. Likewise, the DNS server's DNS service may have stopped. Typically though, these types of problems will affect other clients as well since multiple clients usually rely on a single DNS server.
If DNS name resolution succeeds, it is important that you've verified the IP address was returned during the name resolution process. You can do this by comparing the IP address of the returned to the actual IP address that the remote host is using. These IP addresses should match, but there are conditions that could cause a mismatch, which would result in a communication failure.
If you do encounter an IP address mismatch, it could be the result of a malware infestation on the client, or it could be the result of DNS poisoning. DNS poisoning is a process in which the DNS cache is populated with invalid or incorrect IP addresses.
If you should encounter such a problem, then I would recommend scanning the client machine for malware. It is important to scan for both spyware and viruses since both are known to cause this type of problem. Once the machine is free of malware, then try flushing the DNS cache. You can flush the DNS cache by entering the following command:
IPCONFIG /FLUSHDNS
You can see an example of this, shown in Figure E:
Figure E: Flushing suspect DNS cache that may contain inaccurate information
It is important to keep in mind that just because the DNS cache contains inaccurate IP addresses, it does not always mean that DNS poisoning has taken place. Sometimes hosts are assigned new IP addresses, and it takes the DNS cache a while to become aware of the changes.
Conclusion
In this article, I have explained how you can verify that the local TCP/IP protocol stack is working correctly. I then went on to explain how to test the local host's ability to contact the DNS server and the default gateway server, and how to test host name resolution. In the next part of this series, I will discuss a few more common problems that you can detect using the ping command, and will begin discussing routing issues.
About the author:
Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer, he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
WindowsNetworking.com contains a wealth of networking information for administrators: Featuring information on how to setup and troubleshoot various networks of any size. Also includes a comprehensive archive of hundreds of reviewed networking software and hardware solutions. Frequently updated with articles and tips by a team of leading authors, it remains a favorite within the networking community.
