Interesting Traces - Multiple responses to an ARP request

Looking at the title of this page, I know what you are thinking - you are thinking that somewhere in the network there are two hosts with the same IP address and while this can be a real pain to trace down it is not interesting. Well you are wrong. There are no duplicate addresses. OK you say, so some host somewhere is doing proxy ARPs - nope.

Here is the trace, note that there are two ARP request, one for 192.168.12.153 and then another 192.168.12.138. Each request generates two replies. The replies occur at almost the same time and the two MAC addresses in the "is at" address field are sequential.

No.     Time            Source	           Destination                    Info                           
 1 17:46:19.901125 00:23:54:52:18:6e	Broadcast           Who has 192.168.12.153?  Tell 192.168.12.50
 2 17:46:19.902332 00:04:fc:01:6b:57	00:23:54:52:18:6e   192.168.12.153 is at 00:04:fc:01:6b:57
 4 17:46:19.907824 00:04:fc:01:6b:56	00:23:54:52:18:6e   192.168.12.153 is at 00:04:fc:01:6b:56

 8 17:46:25.148711 00:23:54:52:18:6e	Broadcast           Who has 192.168.12.138?  Tell 192.168.12.50
 9 17:46:25.149815 00:04:fc:01:6b:57	00:23:54:52:18:6e   192.168.12.138 is at 00:04:fc:01:6b:57
11 17:46:25.150364 00:04:fc:01:6b:56	00:23:54:52:18:6e   192.168.12.138 is at 00:04:fc:01:6b:56

Trace #1

Here is the system configuration. The two IP addresses correspond to two interfaces on the system and those interfaces have the two MAC addresses that are in the replies.

[root@164dhcp-1795-831 ~]# ifconfig bond0                                            
bond0     Link encap:Ethernet  HWaddr 00:04:FC:01:6B:56  
          inet addr:192.168.12.153  Bcast:255.255.255.255  Mask:255.255.254.0
          inet6 addr: fe80::204:fcff:fe01:6b56/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:11730470 errors:104357 dropped:0 overruns:0 frame:104357
          TX packets:7149106 errors:0 dropped:0 overruns:0 carrier:0
          collisions:2003518 txqueuelen:0 
          RX bytes:8761843125 (8.1 GiB)  TX bytes:4441675241 (4.1 GiB)

[root@164dhcp-1795-831 ~]# ifconfig bond1
bond1     Link encap:Ethernet  HWaddr 00:04:FC:01:6B:57  
          inet addr:192.168.12.138  Bcast:164.152.255.255  Mask:255.255.0.0
          inet6 addr: fe80::200:ff:fe00:0/64 Scope:Link
          UP BROADCAST RUNNING MASTER MULTICAST  MTU:1500  Metric:1
          RX packets:19336 errors:0 dropped:0 overruns:0 frame:0
          TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:2792322 (2.6 MiB)  TX bytes:1358 (1.3 KiB)

Figure 1 - System Interface Configuration

The system is running Linux 2.6. Both interfaces are on the same subnet so both interfaces will see the broadcast ARP request. It appears that both interfaces also reply with their own MAC address.

This could be considered just an entertaining idiosyncrasy of Linux but the ARP cache on 192.168.12.50 has 192.168.12.138 mapped to 00:04:FC:01:6B:56 because that was the last ARP reply received for 192.168.12.138.

C:\Documents and Settings\noah>arp -a                                                

Interface: 192.168.12.50 --- 0x2
  Internet Address      Physical Address      Type
  192.168.12.1          00-04-96-19-0b-20     dynamic
  192.168.12.34         00-00-a8-41-3b-6e     dynamic
  192.168.12.44         00-00-4c-bf-a7-37     dynamic
  192.168.12.90         00-04-fc-01-10-23     dynamic
  192.168.12.138        00:04:FC:01:6B:56     dynamic
  192.168.12.153        00-04-fc-01-6b-56     dynamic
  192.168.12.100        00-0c-29-a9-85-44     dynamic
  192.168.12.248        00-50-56-bb-42-6e     dynamic
  192.168.12.249        00-0c-29-e3-5b-d4     dynamic

C:\Documents and Settings\noah>

Figure 2 - ARP cache on the client

BUT that MAC address is actually for 192.168.12.153. As long as 192.168.12.153 stays up and is connected to the network its not a problem - but if the interface goes down or is disconnected then 192.168.12.50 can no longer communicate with 192.168.12.138 - at least until the ARP cache entry times out. Testing from another system - one that does not already have ARP cache entries for 164.52.76.153 and 192.168.12.138 will work just fine. Something guaranteed to increase the confusion level of the person tasked with troubleshooting why 192.168.12.50 has lost communication with 174.152.76.138

This page was last modified on 09-06-28

Send comments and suggestions
to ndav1@cox.net