I know that working from the command line can be intimidating to those of us who have always had a nice graphical interface to use. I am convinced, however, once you see how easy to use and effective the following tools are, you will be hooked. Even if you are an old pro, read on. You may find a use for one of these tools that you had not before considered.
The simplest of these tools is the ping utility. Ping is used to see if another IP address is valid and reachable. What ping does is to send a packet to the specified address and wait for it to return. During the interim, the elapsed time is recorded and reported if the packet successfully reaches its destination and an acknowledgement is returned. If, after a predetermined time, the packet does not return the ping command will return with “destination host unreachable”.
In Windows, ping will repeat this process four times, reporting its results as it goes. Linux/Unix/BSD machines will repeat the process until you stop it by pressing “ctrl” and “c” simultaneously. The syntax is straightforward, simply type “ping w.x.y.z” (where w.x.y.z is the IP address of the machine that you are trying to reach). If you have a protocol installed that supports it, you can also ping by NetBIOS name or DNS name. You can type “ping /?” to get a list of useful switches when it is being used under Windows. You can get similar information for *nix/*BSD by typing “man ping”.
One of the most useful switches for ping when it is run under Windows is “ping -a w.x.y.z” . This will return the full DNS name of the target host, if it is available, in addition to the information that is normally returned. To do the same thing with a *nix machine, all that you have to do is use the “host” command. To use host simply enter “host w.x.y.z”.
Keep in mind that if the echo service is not running on the target machine (the machine that you are trying to ping), you will not receive a response. Just a note so that you know that just because you do not get a response does not mean that the machine is down. In these instances, you can use ‘tracert’ or ‘traceroute’ to help determine if a node is up.
You can also use a port scanner, although that is outside the realm of this article. If you are interested in port scanners, be sure to have a look at this article…(see below)
If you cannot ping the host IP address that you had entered, you can still determine a bit more about your network using ping. If you ping your own IP address successfully, you will know that your NIC (Network Interface Card) is functioning correctly.
In the event that pinging your own IP address does not produce desired results, you can ping 127.0.0.1. This address is known as the local loopback address. This will tell you if TCP/IP is installed correctly on your system. If you cannot ping your own IP address and you can not ping your local loopback address, do not run out and buy a new NIC. Simply (re)install TCP/IP on your machine. If you can successfully ping the local loopback address but not your machine’s IP address you may try to reinstall the drivers for your network card.
OK, let’s say you couldn’t ping your destination host and you did not know what your local IP address is, to ping it. You can find out some very important information about your local machine using ipconfig (or ifconfig for you *nix/*BSD people). This will tell you the DNS name of the machine that you are using along with the MAC (Media Access Control) and IP address for all network adapters on your machine.
These tools will also provide some other useful information. If you do not see any evidence of a NIC you will have a pretty good idea that it is not installed properly. If any network adapters have an IP address of 0.0.0.0 (or 169.254.X.X on Windows 2000 machines) you will know that your machine is configured incorrectly and simply need to reconfigure TCP/IP. On a Windows machine you can find a little more information by following the ipconfig command with the “/all” switch. Ipconfig and ifconfig can do much more than just tell you information about your local machine; however that is a bit beyond the scope of this article. For Windows users, you can learn more by using the “/?” switch while you Linux/Unix people will have to read the man pages (man ifconfig) or, depending on your distribution, you may find out more with the –help switch.
Another cool thing that you can do is save the output of ipconfig or ifconfig (or any command from the command line that outputs to standard output – a.k.a. the screen) to a text file for later reference. This is accomplished by following the command with “>filename.txt”. This will work in both Windows and Linux/Unix and can be used to redirect the output of almost any command to a file. This can be very useful for documenting the output of a command.
In small networks that do not use dynamic IP addressing schemes you can print out these text files and tape them inside the case of each machine on the network. This is helpful in the event that you have problems in the future; you will have a handy reference at your disposal.
Suppose that you wanted to see the path that a packet had to take to reach its destination address. If you are using Windows use “tracert” or, if you are using Linux/Unix, use “traceroute” followed by the IP address or DNS name of the target host. This will not only show the latency time between each “hop” but the name (if it is available) and IP address of each node as well.
Another useful tool that is very similar to tracert is pathping. It is used in the same manner as ping or traceroute and will return results that are very similar to traceroute. The major difference between pathping and tracert is that pathping will not only trace the route, but will also send a series of packets to each node (hop) in the path. It then analyzes the latency times (ping times) at each node and will show these times along with the number of packets sent to each node, the number of packets dropped, and percentage of packets that made it to their destination.
What does all of this tell you? Primarily this information is useful in locating bottlenecks in a large routed network. You know that if one node consistently demonstrates higher latency times and/or more packets dropped, this is the weak link in the path and the area to look at first.
In conclusion, you can very quickly diagnose many network connectivity problems with these easy to use tools. Once you become more familiar with them, you will be able to tell even more about the status of your network. Go ahead, try them out and see what you can learn about the network that you are on, even if that network is the internet…
Jay Fougere is the IT manager for the murdok network. He also writes occasional articles. If you have any IT questions, please direct them to Jay@https://murdok.org.
