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 |
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) |
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> |
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