Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
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) bytesof 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]#