Home > Articles > Networking

  • Print
  • + Share This
From the author of


If you have a host that isn't communicating with the other hosts on its network (for example, you can't ping it, nor can the host ping other boxes), looking in the arp cache is a quick check to see if the host is talking to the network or if there is already another host on the network with the same IP address.

An Overview of arp

The arp command takes a variety of options. The most important of these are summarized in Table 2.

Table 2 arp Options

Short Style Option

Long Style Option



(No long option)

Displays all hosts in the BSD style



Sets a new arp entry



Deletes an arp entry



Displays contents without resolving names



Is verbose

Many of these options can be combined to provide better results.The -n option is of particular note here. If an IP address is not resolvable to a hostname, arp will hang for a long time waiting to resolve it. I almost always turn resolving off for networking commands.

arp at Work

In introducing arp as a troubleshooting tool, I mentioned using it to check for more than one host with the same IP address. Next is an example of using arp and ifconfig to find such a problem.

If I had problems communicating between crashtestdummy (at and cherry (at, but could communicate between mango ( and both of the others, I might start by checking the arp cache results on cherry and mango, and looking at the output from ifconfig on crashtestdummy. cherry's arp cache is shown in Listing 7.

Listing 7 cherry's arp Cache

[root@cherry /root]# arp -n
Address      HWtype  HWaddress      Flags Mask  Iface
mango       ether  00:A0:D2:1C:64:E8  C       eth0    ether  00:A0:D2:1C:64:F0  CM      eth0
[root@cherry /root]#

The arp cache for mango is shown in Listing 8.

Listing 8 mango's arp Cache

[root@mango /root]# arp -n
Address      HWtype  HWaddress      Flags Mask  Iface
cherry       ether  00:E0:98:7C:95:21  C       eth0    ether  00:A0:D2:1C:64:DB  C       eth0
[root@mango /root]#

The results of an ifconfig on crachtestdummy are shown in Listing 9.

Listing 9 ifconfig on crashtestdummy

[root@ctd /root]# ifconfig -a
eth0  Link encap:Ethernet HWaddr 00:A0:D2:1C:64:DB
    inet addr: Bcast: Mask:
    RX packets:1293 errors:0 dropped:0 overruns:0 frame:0
    TX packets:488 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    Interrupt:10 Base address:0xfc00
[root@ctd /root]#

If you look at the MAC address of crashtestdummy, you find that it's 00:A0:D2:1C:64:DB, the same value as in mango's arp cache. A different value is lurking in cherry's arp cache, though, indicating our problem.

In this case, though, there is a bit more information to grab that will help us solve our problem: the M flag in's arp cache entry on cherry. This flag indicates a permanent entry, probably entered by hand. If you delete it, things should go back to normal, as shown in Listing 10.

Listing 10 A Healthy Response

[root@cherry /root]# arp -d
[root@cherry /root]# ping
PING ( from : 56(84) bytes
 of data.
64 bytes from icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from icmp_seq=1 ttl=255 time=0.3 ms

-- - ping statistics -- -
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.3/0.5/0.8 ms
[root@cherry /root]# arp -n
Address      HWtype   HWaddress      Flags Mask   Iface
cherry       ether   00:E0:98:7C:95:21  C       eth0    ether   00:A0:D2:1C:64:DB  C       eth0
[root@cherry /root]#
  • + Share This
  • 🔖 Save To Your Account