Home > Articles > Networking

  • Print
  • + Share This
From the author of

arp

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

Purpose

-a

(No long option)

Displays all hosts in the BSD style

-s

--set

Sets a new arp entry

-d

--delete

Deletes an arp entry

-n

--numeric

Displays contents without resolving names

-v

--version

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 192.168.1.20) and cherry (at 192.168.1.10), but could communicate between mango (192.168.1.1) 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
192.168.1.20    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
192.168.1.20    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:192.168.1.20 Bcast:192.168.1.255 Mask:255.255.255.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    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 192.168.1.20'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 192.168.1.20
[root@cherry /root]# ping 192.168.1.20
PING 192.168.1.20 (192.168.1.20) from 192.168.1.10 : 56(84) bytes
 of data.
64 bytes from 192.168.1.20: icmp_seq=0 ttl=255 time=0.8 ms
64 bytes from 192.168.1.20: icmp_seq=1 ttl=255 time=0.3 ms

-- -192.168.1.20 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
192.168.1.20    ether   00:A0:D2:1C:64:DB  C       eth0
[root@cherry /root]#
  • + Share This
  • 🔖 Save To Your Account