Using ping command for troubleshooting networks will help narrow down the causes of your Windows PC connectivity problems. The introduction to this TCP/IP diagnostic utility will give you an understanding and syntax of how ping works, plus what it means when your ping request times out or reaches a network host.
Diagnose issues from the command line (CL) prompt window and learn how to verify network connections in this tip, originally seen on WindowsNetworking.com.
Today's network hardware and software are more reliable than ever; but even so, things do occasionally go wrong. In this article series, I am going to discuss some troubleshooting techniques that you can use when a host on your Windows network has trouble communicating with other network hosts. For the sake of those with less experience in working with the TCP/IP protocol, I'm going to start with the basics, and then work toward the more advanced techniques.
Verify network connectivity
When one host has trouble communicating with another, the first thing that you must do is gather some information about the problem. More specifically, you need to document the host's configuration, find out if the host is having trouble communicating with any other machines on the network, and find out if the problem effects any other hosts.
For example, suppose that a workstation is having trouble communicating with a particular server. That in itself doesn't really give you a lot to go on. However, if you were to dig a little bit deeper into the problem and found out that the workstation couldn't communicate with any of the network servers, then you would know to check for a disconnected network cab...
To continue reading for free, register below or login
To read more you must become a member of SearchNetworking.com
le, a bad switch port, or maybe a network configuration problem.
Likewise, if the workstation were able to communicate with some of the network servers, but not all of them, that too would give you a hint as to where to look for the problem. In that type of situation, you would probably want to check to see what the servers that could not be contacted had in common. Are they all on a common subnet? If so, then a routing problem is probably to blame.
If multiple workstations are having trouble communicating with a specific server, then the problem probably isn't related to the workstations unless those workstations were recently reconfigured. More than likely, it is the server itself that is malfunctioning.
The point is that by starting out with a few basic tests, you can gain a lot of insight into the problem at hand. The tests that I am about to show you will rarely show you the cause of the problem, but they will help to narrow things down so that you will know where to begin the troubleshooting process.
Ping
Ping is probably the simplest TCP/IP diagnostic utility ever created, but the information that it can provide you with is invaluable. Simply put, ping tells you whether or not your workstation can communicate with another machine.
The first thing that I recommend doing is opening a command prompt window, and then entering the ping command, followed by the IP address of the machine that you are having trouble communicating with. When you do, the machine that you have specified should produce four replies, as shown in Figure A.
[IMAGE]
Figure A: Four replies generated after pinging specified machine
The responses essentially tell you how long it took the specified machine to respond with 32 bytes of data. For example, in Figure A, each of the four responses were received in less than four milliseconds.
Typically, when you issue the ping command, one of four things will happen, each of which has its own meaning:
The first thing that can happen is that the specified machine will produce four replies. This indicates that the workstation is able to communicate with the specified host at the TCP/IP level.
The second thing that can happen is that all four requests time out, as shown in Figure B. If you look at Figure A, you will notice that each response ends in TTL=128. TTL stands for "time to live." What this means is that each of the four queries and responses must be completed within 128 milliseconds. The TTL is also decremented once for each hop on the way back. A hop occurs when a packet moves from one network to another. I will be talking a lot more about hops later on in this series.
[IMAGE]
Figure B: Four requests time out after pinging host
At any rate, if all four requests have timed out, it means that the TTL expired before the reply was received. This can mean one of three things:
- Communication problems are preventing packets from flowing between the two machines: This could be caused by a disconnected cable, a bad routing table, or a number of other issues.
- Communications are occurring, but are too slow for ping to acknowledge: This can be caused by extreme network congestion, or by faulty network hardware or wiring.
- Communications are functional, but a firewall is blocking ICMP traffic: Ping will not work unless the destination machine's firewall (and any firewalls between the two machines) allow ICMP echoes.
A third thing that can happen when you enter the ping command is that some replies are received, while others time out. This can point to bad network cabling, faulty hardware, or extreme network congestion.
The fourth thing that can occur when pinging a host is that you receive an error similar to the one that is shown in Figure C.
[IMAGE]
Figure C: Error message indicating that TCP/IP is misconfigured
A Transmit Failed error indicates that TCP/IP is not configured correctly on the machine on which you are trying to enter the ping command. This particular error is specific to Vista though. Older versions of Windows produce an error when TCP/IP is configured incorrectly, but the error message is "Destination Host Unreachable."
What if the ping is successful?
Believe it or not, it is not uncommon for a ping to succeed, even though two machines are having trouble communicating with each other. If this happens, it means that the underlying network infrastructure is good, and that the machines are able to communicate at the TCP/IP level. Typically, this is good news, because it means that the problem that is occurring is not very serious.
If normal communications between two machines are failing, but the two machines can ping each other successfully (be sure to run the ping command from both machines), then there is something else that you can try. Rather than pinging the network host by IP address, try replacing the IP address with the host's fully qualified domain name, as shown in Figure D.
[IMAGE]
Figure D: Pinging network host by its fully qualified domain name
If you are able to ping the machine by its IP address, but not by its fully qualified domain name, then you most likely have a domain name system (DNS) issue. The workstation may be configured to use the wrong DNS server, or the DNS server may not contain a host record for the machine that you are trying to ping.
If you look at Figure D, you can see that the machine's IP address is listed just to the right of its fully qualified domain name. This proves that the machine was able to resolve the fully qualified domain name. Make sure that the IP address that the name was resolved to is correct. If you see a different IP address than the one you expected, then you may have an incorrect DNS host record.
Conclusion
In this article, I have shown you some steps for testing basic connectivity between two machines by using ping commands, and I showed you what those ping responses could mean to your hosts connectivity. In the next article in the series, I will show you some more techniques that you can use in the troubleshooting process.
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.
[IMAGE]
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.
