Pinging a host is usually the first step in determining if the host is properly connected to the network. If the host does not respond to a ping request, the host is usually assumed to be offline.
But is it?
Today almost every organization employs firewalls for enhanced security. Firewalls can be set up in such a way that Internet Control Message Protocol (ICMP) requests are blocked, which means that traditional pings do not work. Setting a firewall to block ICMP requests is based on the theory that if a would-be hacker cannot "see" the target, he may not attack the host.
This makes system and network administration more difficult. A failed ping is no longer a valid test -- the user may have enabled a firewall that is blocking the ping, but the host may still be up. Before a network administrator can accurately determine if a host is down, the user needs to turn off all firewall applications -- or at least turn off any rules blocking ICMP -- which is probably asking too much of the average user.
ICMP vs. ARP
If traditional ICMP-based pings are no longer reliable unless you know in advance that there is no firewall blocking ICMP echo requests, what other options exist? One option is an Address Resolution Protocol (ARP) based ping using the arping utility.
To know why ARP pings are virtually guaranteed to work while ICMP pings may not, one should understand the importance of ARP in networking. ARP is used by hosts on a network to resolve IP addresses into Media Access Control (MAC) addresses, which can be interpreted as a network interface's unique serial number. Hosts on an Ethernet network use MAC addresses rather than IP addresses to communicate.
When a host tries to create a connection to another host (on the same subnet), it first needs to obtain the second host's MAC address. In this process, Host A sends an ARP request to the broadcast address of the subnet to which it is connected. Every host on the subnet receives this broadcast, and the host with the IP address in question sends an ARP reply back to Host A with its MAC address. After receiving the ARP reply from Host B, Host A can connect to Host B.
ARP is required for an Ethernet network to function properly, so it typically is not blocked by a firewall. If ARP requests were blocked, no host would be able to "find" a computer on a network and connect to it. For all intents and purposes, the system would be unplugged from the network.
(Tools do exist to filter ARP. The ebtables project provides these tools. Ebtables is similar in both functionality and syntax to iptables, but whereas iptables works with TCP and UDP protocols, ebtables works with ARP.)
One possible drawback to this system of using ARP to ping a host is that the ARP protocol is not a routed protocol. If you are not on the same subnet as the host you are trying to connect to, then this method is not going to work without first joining that subnet, which may or may not be physically possible. Thus by sending an ARP request rather than an ICMP echo, you are virtually guaranteed to get a reply.
Let's explore the most convenient ways to obtain ARP replies.
When you attempt to ping an IP address, an ARP request is sent at the same time. Your firewall may be blocking the ICMP echo, but chances are the computer will receive an ARP reply. Your computer's ARP table will contain the IP address and MAC address of the host you are trying to reach.
Let's look at some of the ways to view the ARP tables. The first option is to use the
ip neighbor command:
gerard@garion:~$ ip neighbor | grep 192.168.1.100
192.168.1.100 dev eth0 lladdr 00:40:05:01:fc:1e nud reachable
ip utility used here is part of the relatively new package iproute2 that is designed to replace traditional utilities such as
arp. If your Linux system does not come with iproute2 installed, you can use
arp instead of
In this example, the IP address has a MAC address (lladdr) and a Neighbor Unreachability Detection (nud) of reachable in the ARP table. This means that the host belonging to IP address 192.168.1.100 is online and active, but is apparently blocking ICMP echo requests.
If this host were truly offline, the
ip neighbor command's output would be similar to this:
gerard@garion:~$ ip neighbor | grep 192.168.1.101
192.168.1.101 dev eth0 nud failed
A nud of
failed means there was no ARP reply after having sent out the ARP request to find this host.
Ethereal and tcpdump
If you're running the regular
ping command on the 192.168.1.100 IP address, and run the
tcpdump -n command or Ethereal, you'll see output similar to this:
12:28:59.632396 arp who-has 192.168.1.100 tell 192.168.1.1
12:28:59.632592 arp reply 192.168.1.100 is-at 00:40:05:01:fc:1e
The first line shows that 192.168.1.1 is trying to find 192.168.1.100. The second line shows that the host replies with its MAC address. This host is definitely online even though it is blocking ICMP echoes.
It can be a bit cumbersome having to run two programs like this at the same time. This is where the
arping program comes in.
Arping program works like the traditional ping command. You give it an IP address to ping, and arping sends the proper ARP request. Arping then listens for ARP replies and prints them (if any), including the ping reply time:
root@garion:/home/gerard# arping 192.168.1.100
60 bytes from 00:40:05:01:fc:1e (192.168.1.100): index=0 time=190.973
This tool makes pinging hosts quick and easy. You no longer have to run additional tools to view your ARP table or otherwise view ARP replies.
Another good use for arping is the ability to detect whether more than one host is configured to use the same IP address:
root@garion:/home/gerard# arping 192.168.1.100
60 bytes from 0a:00:3e:f1:bf:49 (192.168.1.100): index=0 time=191.151
60 bytes from 00:02:b3:99:2c:f8 (192.168.1.100): index=1 time=192.419
Here, two machines are replying to queries for the same IP address, which can lead to all kinds of problems.
ARP pinging can be a useful ICMP ping replacement on Ethernet networks. With it, you can confidently take firewalls out of the equation and know that a failed ARP ping indicates a real problem that has to be looked into.