Probably the most common tool that people use for checking their network is a command called ping. You can ping a host or an interface to see if it responds. In the output response from issuing the ping command, you are shown the time it has taken for that response to come back. You can ping the other side of the world and receive a response in milliseconds. That is good. If you get response times in the order of whole seconds or a “host unreachable” message, that is bad. Of course, if the host you’re pinging is on another continent or connected via a satellite link, ping times will be higher than if the host is sitting under your desk.
I just used the ping command to test our routes as follows:
PING 192.168.0.50 (192.168.0.50) 56(84) bytes of data.
64 bytes from 192.168.0.50: icmp_seq=1 ttl=64 time=1.24 m
The ping command can take the following arguments. For other arguments, refer to the man page.
The ping command will send pings to a host indefinitely unless you either stop it, using Ctrl+C usually, or give it the number of pings to attempt using the –c number option.
You can also express the interval between pings as –i number (in seconds) and choose the interface you wish to use as the source address, specified by -I IP address or the interface name like: -I enp0s8. This is very handy if you have multiple interfaces and wish to test one of those. If you don’t define an address, it will normally ping using the primary interface on the host, usually eth0. You can also specify the packet size, using -s number of bytes, which is useful for testing bandwidth problems or problems with MTU settings.
MTU is the maximum transmission unit. it is used to limit the size of the packets to what the network devices on that network can handle. Normally it is set to 1,500 bytes, but with jumbo frames it can be up to 9,000 bytes. Having larger-sized packets should mean that you can send more data more efficiently due to less packets traveling over the wire.
One of the first things you can do to test your network is to use ping to ping the interfaces you have configured. If they respond to pings from your own host, they are up and your interface is responding to TCP traffic. You can do this as follows:
PING 192.168.0.253 (192.168.0.253) 56(84) bytes of data.
64 bytes from 192.168.0.253: icmp_seq=2 ttl=128 time=1.68 ms
Here we have sent a ping to the local IP address of our host, and we can see a series of responses indicating that a connection has been made and the time it took. If we had received no responses, we would know something is wrong with our interface or network.
The next step is to ping another host on your network, like your default gateway or your DNS server (these two hosts are critical for your Internet communications).
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=128 time=2.97 ms
If you can get there, you know that your host can reach other hosts. You would then ping a host outside your network, say www.ibm.com or www.google.com, and test its response:
PING google.com (22.214.171.124) 56(84) bytes of data.
64 bytes from par21s11-in-f14.1e100.net (126.96.36.199): icmp_seq=1 ttl=53 time=6.31 ms
When you experience problems connecting to hosts on the Internet, it can be for many reasons. There are instances in which part of the Internet will go down because a core router is broken. In this situation, all your private network pings will return, but some pings to hosts on the Internet may not. If you don’t get a response from one host on the Internet, try another to see if the issue is local or somewhere else down the line. Some remote networks will actively block ICMP (Internet Control Message Protocol) traffic. These hosts will not respond to pings, and so you should check the response of other hosts before you panic. It is also handy in these situations to combine your investigations with other tools, such as mtr or traceroute.
Published on Mon 08 September 2003 by Alistair Pinter in Linux with tag(s): ping