Common tools that I find most programmers (and even some network admins!!) know nothing about are the basic networking and DNS related utilities. Typically a service will stop working or errors will crop up and I find it’s a DNS related issue rather than a programming issue. I find this to be especially true when dealing with email servers.
In any case, when diagnosing problems about why your program can’t talk to a server, printer, or client, or when trying to gather information about an IP address or hostname, I find a few tools extremely helpful: Ping, Dig, Whois, and Nslookup.
All of these tools are basic tools included with any Linux distro, and some are even included with your windows machine (ping & nslookup). Below I will describe the common ways I uses these tools in my day to day life. What I present below are extremely simple summaries. Once you’re comfortable with the basics, and if you’re on a unix platform, you should read the man pages about them to understand all the additional options they have.
This particular blog post will concentrate on the ping utility. I will then follow up with posts on the other tools nslookup, dig, and whois to complete the series of information.
Now off to learning the basics of Ping!
Ping
Ping is perhaps the simplest utility used to test network connectivity and whether a particular server is up. The way ping works is it sends an ICMP ECHO_REQUEST packet to the target host and then listens for the ICMP ECHO_RESPONSE packet coming back.
I most commonly use ping to check if a host, printer, or server on my network is responding. I also use it to tell me when a remote server reboot is almost done by telling ping to run indefinitely until I cancel it. Lastly, I use ping just to quickly see what types of latency is occurring in packets between two servers.
To ping a host, run the simple commands below.
On Unix:
ping google.com
After a few seconds press the ctrl-c key combination to cancel the ping, and the output will look something like what I show below:
PING google.com (64.233.187.99) 56(84) bytes of data. 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=0 ttl=237 time=36.4 ms 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=1 ttl=238 time=34.0 ms 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=2 ttl=238 time=36.4 ms 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=3 ttl=238 time=34.1 ms 64 bytes from jc-in-f99.google.com (64.233.187.99): icmp_seq=4 ttl=238 time=36.5 ms --- google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4002ms rtt min/avg/max/mdev = 34.012/35.527/36.576/1.209 ms, pipe 2
On Windows:
To run ping on windows you first need to go to your dos prompt. Then run:
ping google.com
Windows will automatically send 4 ping requests and then stop. No need to press ctrl-c to cancel it. The output will look something like what I show below:
Pinging google.com [64.233.187.99] with 32 bytes of data:
Reply from 64.233.187.99: bytes=32 time=35ms TTL=238
Reply from 64.233.187.99: bytes=32 time=36ms TTL=237
Reply from 64.233.187.99: bytes=32 time=34ms TTL=238
Reply from 64.233.187.99: bytes=32 time=36ms TTL=238
Ping statistics for 64.233.187.99:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 34ms, Maximum = 36ms, Average = 35ms
If you want to run ping indefinitely on windows you will use the -t option. I commonly do this when I remotely reboot a server and want to see when it kills its network connections during the shutdown and then when it is back up. I’ll run the ping command below and just watch the output.
ping -t timarcher.com
If you see ping start saying ”request timed out” then you know the remote host is not answering your ping requests, and could be down. The output of this looks like:
Pinging somedomain.com [111.11.111.111] with 32 bytes of data: Request timed out. Request timed out. Request timed out.
However, sometimes if you ping a remote firewall, it may not answer to your ping requests for security reasons, giving you the false impression that the host is down. This is the other error I see sysadmins commonly make. To be sure that ping is reliable for you, first test it out and make sure you can ping the host when you know it is up and responding, and if so, then it should be alright to use in the future.
The last key important component of your ping output is the round trip time of each packet between the hosts and the overall statistics shown when the pinging is done. Looking back at our ping to google.com, we see that 5 individual pings were sent, and the first packet’s round trip time from my machine to google.com took 36.4 milliseconds, the second trip took 34.0 milliseconds, and so on. Lastly, when the pinging is complete, the overall statistics are printed. In our case it these statistics looked like:
--- google.com ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 4002ms rtt min/avg/max/mdev = 34.012/35.527/36.576/1.209 ms, pipe 2
These overall statistics tell me that 5 packets were sent out, I received 5 responses, and no packets were lost. Lost packets can be an indication of network failures, excessive traffic, etc.
Now that I’ve shown you how to do some of the basics with ping, let me list some situations on when I use it:
- When rebooting servers remotely to see when they come back online.
- When setting up new network printers to ensure it’s basic TCP/IP configuration is setup.
- When troubleshooting any connectivity issues such as servers that cannot communicate, switches that are flaking out, etc.
- When I suspect the network is slow to excessive traffic or other problems. I’ll ping a server I know has a good response time and look for anomalies here in response times, or even if it is intermittently timing out on ping requests..
In summary, ping is a very simple, but very useful, utility to test network connectivity.
The next post in this series will concentrate on using nslookup to test DNS configurations.
Comments
Leave a comment Trackback