This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature

Ping: ICMP vs. ARP

By Gerard Beekmans on December 22, 2005 (8:00:00 AM)

Share    Print    Comments   

Network and system administrators are well-versed in using the ping utility for troubleshooting purposes, but where do you turn when ping doesn't do the trick?

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.

ARP table

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

The ip utility used here is part of the relatively new package iproute2 that is designed to replace traditional utilities such as ifconfig, route, and arp. If your Linux system does not come with iproute2 installed, you can use arp instead of ip neighbor.

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

Another approach is to use the tcpdump and Ethereal utilities to look at live network traffic, including ARP requests and replies.

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

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
ARPING 192.168.1.100
60 bytes from 00:40:05:01:fc:1e (192.168.1.100): index=0 time=190.973 usec

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
ARPING 192.168.1.100
60 bytes from 0a:00:3e:f1:bf:49 (192.168.1.100): index=0 time=191.151 usec
60 bytes from 00:02:b3:99:2c:f8 (192.168.1.100): index=1 time=192.419 usec

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.

Share    Print    Comments   

Comments

on Ping: ICMP vs. ARP

Note: Comments are owned by the poster. We are not responsible for their content.

yeah, so what?

Posted by: Anonymous Coward on December 22, 2005 06:05 PM
If you really have a large ethernet segment with each host running its own firewall you really need to look over your network configuration.

In case you didn't know, a mac address never leaves the current ethernet segment which makes it quite useless to use arpping instead of an icmp echo request.

If you want to know which hosts that are up on your current segment just look at the arp table for segments router och look at the switch if it's managmentable.

Maybe you should read up on basic OSI layers before comparing apples and oranges.

#

Re:yeah, so what?

Posted by: Anonymous Coward on December 22, 2005 07:35 PM
Well, as it turns out, many people have to administer networks incorporating Windows XP clients, which have just enough network services disabled to be annoying by default. Now, many of those are administered by the sysadmin(s)/help desk/etc., but for the particular purpose of an 802.11a/g network at a uni, or some other similar public access purpose, this is a godsend. Yeah, the two are very different mechanisms, but the result is the same; You can check for physical network connectivity. If you wish, you can then extend that with a ping from the same subnet (to check whether it filters pings) and then a ping from a remote subnet (to check whether its routing table is hosed). So, all in all, arping can be a very useful tool for many purposes<nobr> <wbr></nobr>:)

Cheers,

Michael

#

Re:yeah, so what?

Posted by: Anonymous Coward on December 22, 2005 07:50 PM
Maybe you should read the article more carefully.



"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."



Or maybe you did read this, and you're just trolling.



---------------

Giannis

#

Re:yeah, so what?

Posted by: Anonymous Coward on December 27, 2005 09:17 PM
... and then the sentence right after that says "Thus by sending an ARP request rather than an ICMP echo, you are virtually guaranteed to get a reply."

A seeming contradiction, even though I say so myself. This article desperately needs peer review and technical editing. From my vantage point as an IT security specialist who has worked with the TCP/IP suite of protocols for eight years, I rate this article as useless. And oh yeah, I'll be going throuh CCIE training in March (I gotta renew this useless, @#$#$ CCNP certification of mine, so I might as well do something worthwhile).

#

Re:yeah, so what?

Posted by: Anonymous Coward on December 27, 2005 11:46 PM
I don't have a CCNP, a CCIE, or an ABCD, but I understood the article, and its description of the limitations of ARP, perfectly well. Did it start out overhyping the usefullness of ARP? Maybe. But its limitations were pretty clearly mentioned. Maybe you should put down that technical training manual and pick up a book on simple reading comprehension.

#

Re:yeah, so what?

Posted by: Anonymous Coward on May 11, 2007 03:22 PM
CCIE, yeah, so what?

#

Re:yeah, so what?

Posted by: Administrator on December 22, 2005 11:09 PM
I read it and missed it.

#

Back Pain relief

Posted by: Anonymous Coward on May 28, 2006 01:49 PM
[URL=http://painrelief.fanspace.com/index.htm] Pain relief [/URL]

  [URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]

  [URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.com] Pain relief [/URL]
[URL=http://nervepainrelief.jeeran.com/painrelief<nobr>.<wbr></nobr> htm] Nerve pain relief [/URL]

#

ARP and ICMP are two completely different beasts

Posted by: Anonymous Coward on December 22, 2005 07:33 PM
ARP is a protocol that associates IP addresses with their (usually Ethernet) hardware address.

ICMP is a communication protocol designed to send a packet to a remote host and receive a response.

ARP has no relevance outside of the current network segment or across any type of router, because the information is not exchanged. ARP works by caching IP->HW address information; recent changes to the network may not be identified.

All arping does is forces a check for the association (by sending a broadcast packet) requesting a resolution for the IP address, and it expects the hardware ethernet address in response. The response to that broadcast information may not come from the true host (although arping will report the resoinse source). But it's perfectly possible for the response to come from a router or other host on the network; the response could even have been masqueraded to appear to come from your host. And that host may be mistaken about the association anyway, because the only data it has is in a cache which may be out of date.

Because arping is limited to broadcasting for IP->HW data it is completely unable to verify the *actual* availability of the host. The host could be down, have recently disconnected from the network, or arping may report erroneous unavailability just because it never got a response for the association request.

For example, arping will be unable to verify if localhost is available, because 127.0.0.1 is never associated with your hardware ethernet address; it's a purely logical association within the network drivers/kernel.

Basically, using ARP and arping is about as useful as looking up the contents of your<nobr> <wbr></nobr>/etc/ethers on the basis that the information in there *may* be correct. Looking in<nobr> <wbr></nobr>/etc/ethers won't tell you the availability of the host you are looking for either.

Since arping is unable to communicate beyond your local segment or router, using arping for anything beyond checking hardware ethernet->IP addresses is a complete waste of time.

ICMP *IS* useful both within and beyond your current network segment because it actually sends packets through the normal routing mechanism to the destination host. ping does not send a broadcast asking if anybody knows the host, it actually tries to communicate with the host. ping will also correctly resolve logical hosts like localhost and correctly report whether localhost is communicable - vital, in some circumstances, to verify if network is working correctly.

What ping/ICMP is unable to do is determine whether the lack of a response from the host is because it's down or because ICMP packets are disabled or filtered. You can at least route traceroute to determine how far your ICMP data is getting if you don't get a response.

Using ping does, at least, actually try to contact the host.

Oh, and ARP reports the *DEVICES* that may have been configured with the same IP address, not the *HOST* as stated in the article; both devices could be in the same host and could, theoretically, be perfectly valid. That doesn't mean arping is not useful, but there is a big difference between network device and host.

#

Re:ARP and ICMP are two completely different beast

Posted by: Anonymous Coward on December 22, 2005 10:39 PM
Naah, not all that bad. ARPing works fine instead of ICMP echo pings, as long as you're not leaving your subnet or play with TTL over bridges or play with the ICMP packet size. It's not just broadcast. It's not just a cache lookup (that would be ARP alone). You can do unicast ARP as well. And ARP may be the only indication that there's a host up and running that is otherwise firewalled by a stupid admin blocking ICMP (not that you can't block ARP either, but usual Windows-PFWs don't do that). If another machine answers that arp request, that may be useful information, too.

#

Pain

Posted by: Anonymous Coward on May 28, 2006 02:01 PM
<tt>[URL=http://painrelief.fanspace.com/index.htm] Pain relief [/URL]
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.c<nobr>o<wbr></nobr> m] Pain relief [/URL]
[URL=http://nervepainrelief.jeeran.com/pa<nobr>i<wbr></nobr> nrelief.htm] Nerve pain relief [/URL]</tt>

#

That's Just Weird

Posted by: Anonymous Coward on December 22, 2005 11:01 PM
What's the point of all this? I won't reiterate the posts above, about why arp is a poor replacement for ping. But, if you must go this route why do you need special packages like arping(which requires running as root) and ip?

If you are determined to utilize arp to try to verify the presence of a host on the local subnet simply:
ping desired-host
<nobr> <wbr></nobr>/sbin/arp | grep desired-host-ip

This works on any system and requires no special packages. On Windows:
ping desired-host
arp -a desired-host-ip

This works because the ping must first issue an arp request. It fails for the reasons listed in previous posts like routers responding and proxy arp(that's always fun).

#

Pain

Posted by: Anonymous Coward on May 30, 2006 01:14 AM
[URL=http://nervepainrelief.jeeran.com/painrelief<nobr>.<wbr></nobr> htm] Nerve pain relief [/URL]
[URL=http://www.back.painreliefnetwork.net/lowbac<nobr>k<wbr></nobr> pain.htm] Low back pain [/URL]
[URL=http://blog.gala.net/uploads/painreliefback/<nobr>b<wbr></nobr> ackpainrelief.htm] Back pain relief [/URL]
[URL=http://www.weblog.ro/usercontent/13155/profi<nobr>l<wbr></nobr> es/kneepainrelief.htm] Knee pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Pain-R<nobr>e<wbr></nobr> lief.html] Pain relief [/URL]
[URL=http://www.sitefights.com/community/scifi/pa<nobr>i<wbr></nobr> nrelief/painreliefpreved.htm] Pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Medica<nobr>t<wbr></nobr> ion-Pain-Relief.html] Medication pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Natura<nobr>l<wbr></nobr> -Pain-Relief.html] Natural pain relief [/URL]


[URL=http://painrelief.fanspace.com/index.htm] Pain relief [/URL]
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.com] Pain relief [/URL]

#

Back Pain relief

Posted by: Anonymous Coward on May 30, 2006 01:23 AM
<tt>[URL=http://nervepainrelief.jeeran.com/painrelief<nobr>.<wbr></nobr> htm] Nerve pain relief [/URL]
[URL=http://www.back.painreliefnetwork.net/lowbac<nobr>k<wbr></nobr> pain.htm] Low back pain [/URL]
[URL=http://blog.gala.net/uploads/painreliefback/<nobr>b<wbr></nobr> ackpainrelief.htm] Back pain relief [/URL]
[URL=http://www.weblog.ro/usercontent/13155/profi<nobr>l<wbr></nobr> es/kneepainrelief.htm] Knee pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Pain-R<nobr>e<wbr></nobr> lief.html] Pain relief [/URL]
[URL=http://www.sitefights.com/community/scifi/pa<nobr>i<wbr></nobr> nrelief/painreliefpreved.htm] Pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Medica<nobr>t<wbr></nobr> ion-Pain-Relief.html] Medication pain relief [/URL]
[URL=http://www.info.painreliefnetwork.net/Natura<nobr>l<wbr></nobr> -Pain-Relief.html] Natural pain relief [/URL]

[URL=http://painrelief.fanspace.com/index.htm] Pain relief [/URL]
[URL=http://lowerbackpain.0pi.com/backpain.htm] Back Pain [/URL]
[URL=http://painreliefproduct.guildspace.com] Pain relief [/URL]
[URL=http://painreliefmedic.friendpages.c<nobr>o<wbr></nobr> m] Pain relief [/URL]
</tt>

#

hping?

Posted by: Anonymous Coward on December 23, 2005 04:30 AM
I wont go into the usual points of ARP only working in the current subnet, but I was surprised hping wasn't mentioned. hping (or Hidden Ping) was designed to extend far beyond where ping stops. hping allows one to "ping" a remote ip with TCP SYN,ACK,FIN,RST packets, UDP packets, ICMP packets, raw IP packets or even send a file using the data segments of IP/ICMP/TCP/UDP packets. While arping is useful, hping is also worth a look.

#

Re:Was there a technical editor?

Posted by: Anonymous Coward on December 23, 2005 08:18 AM
Perhaps you should re-read the article before trolling on.

In reply to your post:

1. Title is Ping: ICMP vs ARP - as in, ICMP Ping vs ARP Ping

2. Not necessary in the context of the article. If you need to review Layer 3 and Layer 2 differences feel free to read the wiki yourself.

3. And?

4. You've already corrected yourself on this one.

Bottom line is, read the article before trying to show off your self perceived technical knowledge.

I think the article gives the novice networker a good understanding of the technique.

#

Re:Was there a technical editor?

Posted by: Anonymous Coward on January 17, 2006 06:58 PM
1. It compares two protocols
2. This might have been interesting, but the technical level of the article suggested not.
3. So what?
4. This is false

The technical content is adequat. Your response does not seem so.


  - jon

#

Was there a technical editor?

Posted by: Administrator on December 22, 2005 10:42 PM
Sorry, but I have to make a few observations on what should have been detected with a technical review.

1. Title ICMP vs. ARP: ICMP is more than just ping, and based on the body it should be ping not ICMP.

2. No description of Layer 3 and layer 2 differences. <a href="http://www.webopedia.com/quick_ref/OSI_Layers.asp" title="webopedia.com">http://www.webopedia.com/quick_ref/OSI_Layers.asp</a webopedia.com>

3. Ebtables is to Layer 2 as Iptables is to IP (which is layer 3 and supports more than just TCP and UDP).

4. No mention that arp is only valid on a local subnet.

Bottom line this should be removed, rewritten and reviewed for technical accuracy and understandability.

#

Re:Was there a technical editor?

Posted by: Administrator on December 22, 2005 11:06 PM
OK I missed a reference to the fact that you need to be on the same local subnet, but I was not the only one.

Based on all the feedback I have seen this is not readily apparent.

#

Ping: ICMP vs. ARP

Posted by: Anonymous [ip: 122.167.219.9] on October 18, 2007 12:00 PM
nfffff

#

Ping: ICMP vs. ARP

Posted by: Anonymous [ip: 122.167.66.25] on February 21, 2008 02:19 PM
How do ping ICMP vs ARP

#

Ping: ICMP vs. ARP

Posted by: Anonymous [ip: 10.96.36.89] on March 10, 2008 04:50 PM
I kind of amazed at the audacity of some of the posters here, who apparently think this is a stage on which to glorify themselves. Well, guys, not only you don't impress me a bit, you've shown yourselves to be lousy readers, have veryl little to show off and of little patience! Those exalting ICMP ping tend to forget, due to utter ignorance, as far as I'm concerened, that Ping depends on ARP to start with. Whether or not ARP retrieves stale information has nothing to do with its integrity: if Ping depends on ARP it suffers the same shortcoming!
the rest isn't worth commenting.

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya