If you would like to read other parts to this article please go to:
If you would like to be notified when Brien M. Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
In the previous article in this series, 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.
The first test that you need to perform is 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
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: You should receive a successful ping when you attempt to ping the local host address
Pinging the local host address does nothing to diagnose communications 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 or 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: Pinging the default gateway verifies 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, 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 to 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: You should verify that the host can communicate with your DNS server
Another thing that you can do 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 tells you whether or not your DNS server is able to 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, that it is important that you’ve verified the IP address that 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 of the communications failure.
If you do encounter a 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 a 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.
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.
Figure E: If you suspect that your DNS cache may contain inaccurate information, then you must flush it
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.
If you would like to read other parts to this article please go to:
If you would like to be notified when Brien M. Posey releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
