Windows server sending constant ARP requests to offline devices

Question

We have a Windows 2003r2 server which is sending intermittent ARP requests to several devices which are no longer on the network. The result of this is disruption to a PLC which is running over modbus.
The server runs DHCP, Print Services and File Sharing on our network and we have not yet tried turning it off. It is running on a dedicated IBM server with teaming on the NICs.
At it's worst, the server will send out about 4 Who Has requests in the space of 1 milli second to the same group of devices, of which, the PLC is one of them - this is odd as it is on the network - maybe it doesn't support ARP?

No.     Time               Source                Destination           Protocol Length Info
1522 11:49:26.578133000 Ibm_28:2d:e6          Broadcast             ARP      60     Who has 192.168.6.245?  Tell 192.168.6.227 (duplicate use of 192.168.6.227 detected!)

Frame 1522: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Ibm_28:2d:e6 (00:14:5e:28:2d:e6), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
[Duplicate IP address detected for 192.168.6.227 (00:14:5e:28:2d:e6) - also in use by 00:14:5e:28:2d:e7 (frame 1437)]
Address Resolution Protocol (request)

No.     Time               Source                Destination           Protocol Length Info
   1523 11:49:26.578137000 Ibm_28:2d:e6          MoxaTech_2d:ec:26     ARP      60         Who has 192.168.6.193?  Tell 192.168.6.227 (duplicate use of 192.168.6.227 detected!)

Frame 1523: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Ibm_28:2d:e6 (00:14:5e:28:2d:e6), Dst: MoxaTech_2d:ec:26 (00:90:e8:2d:ec:26)
[Duplicate IP address detected for 192.168.6.227 (00:14:5e:28:2d:e6) - also in use by     00:14:5e:28:2d:e7 (frame 1437)]
Address Resolution Protocol (request)

No.     Time               Source                Destination           Protocol Length Info
   1524 11:49:26.578139000 Ibm_28:2d:e6          192.168.6.73          ARP      60         Who has 192.168.6.73?  Tell 192.168.6.227 (duplicate use of 192.168.6.227 detected!)

Frame 1524: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Ibm_28:2d:e6 (00:14:5e:28:2d:e6), Dst: 192.168.6.73      (00:15:b7:44:58:52)
[Duplicate IP address detected for 192.168.6.227 (00:14:5e:28:2d:e6) - also in use by    00:14:5e:28:2d:e7 (frame 1437)]
Address Resolution Protocol (request)

No.     Time               Source                Destination           Protocol Length Info
   1525 11:49:26.578148000 192.168.6.73          Ibm_28:2d:e6          ARP      42         192.168.6.73 is at 00:15:b7:44:58:52 (duplicate use of 192.168.6.227 detected!)

Frame 1525: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface 0
Ethernet II, Src: 192.168.6.73 (00:15:b7:44:58:52), Dst: Ibm_28:2d:e6     (00:14:5e:28:2d:e6)
[Duplicate IP address detected for 192.168.6.227 (00:14:5e:28:2d:e6) - also in use by  00:14:5e:28:2d:e7 (frame 1437)]
 Address Resolution Protocol (reply)

No.     Time               Source                Destination           Protocol Length Info
   1526 11:49:26.578723000 Ibm_28:2d:e6          Inventec_88:ea:a4     ARP      60     Who has 192.168.6.38?  Tell 192.168.6.227 (duplicate use of 192.168.6.227 detected!)

Frame 1526: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Ibm_28:2d:e6 (00:14:5e:28:2d:e6), Dst: Inventec_88:ea:a4 (00:26:6c:88:ea:a4)
[Duplicate IP address detected for 192.168.6.227 (00:14:5e:28:2d:e6) - also in use by  00:14:5e:28:2d:e7 (frame 1437)]
Address Resolution Protocol (request)

No.     Time               Source                Destination           Protocol Length Info
   1527 11:49:26.578725000 Ibm_28:2d:e6          Hewlett-_dc:a8:b2     ARP      60         Who has 192.168.6.200?  Tell 192.168.6.227

Frame 1527: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Ibm_28:2d:e6 (00:14:5e:28:2d:e6), Dst: Hewlett-_dc:a8:b2 (b4:99:ba:dc:a8:b2)
Address Resolution Protocol (request)

No.     Time               Source                Destination           Protocol Length Info
   1528 11:49:26.578727000 Ibm_28:2d:e6          192.168.6.56          ARP      60         Who has 192.168.6.56?  Tell 192.168.6.227 (duplicate use of 192.168.6.227 detected!)

Frame 1528: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Ibm_28:2d:e6 (00:14:5e:28:2d:e6), Dst: 192.168.6.56 (00:00:54:10:77:b5)
[Duplicate IP address detected for 192.168.6.227 (00:14:5e:28:2d:e6) - also in use by 00:14:5e:28:2d:e7 (frame 1527)]
Address Resolution Protocol (request)

No.     Time               Source                Destination           Protocol Length Info
   1529 11:49:26.578729000 Ibm_28:2d:e6          Fuji-Xer_2a:7f:c6     ARP      60         Who has 192.168.6.245?  Tell 192.168.6.227 (duplicate use of 192.168.6.227 detected!)

Frame 1529: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Ibm_28:2d:e6 (00:14:5e:28:2d:e6), Dst: Fuji-Xer_2a:7f:c6 (08:00:37:2a:7f:c6)
[Duplicate IP address detected for 192.168.6.227 (00:14:5e:28:2d:e6) - also in use by 00:14:5e:28:2d:e7 (frame 1527)]
Address Resolution Protocol (request)

Included is a capture from Wireshark which is monitoring the PLC port on the switch. the output above is repeated another 5 times one after another. This in turn kills the modbus output.
It seems to happen on a semi regular basis - it will spit out about 40 frames (4 or 5 iterations) like above, and then 3 seconds later, it will spit out only the one lot (one iteration).
I have: Restarted print services; flushed ARP cache; and made sure that those hosts defiantly do not exist.
Any help would be greatly appreciated!!
Edit: Image attached:
Wireshark Capture

What NIC teaming mode are you using? – joeqwerty Oct 03 '12 at 04:43 — joeqwerty, Oct 03 '12 at 04:43

score 1 · Answer 1 · answered Oct 03 '12 at 04:19

If your PLC is failing because of some stray ARP packets when I think you'd do well to isolate the PLC network! That's not an excessive amount of traffic and, unless there's a MAC or IP address conflict w/ the PLC I really don't see how / why the PLC should be failing.

It looks like the teamed NICs are both answering for the same IP, if I'm reading this right. I don't think that's your problem, but I did want to call it out as a possible red herring.

It's possible that you have some service on the machine that is attempting to communicate with these now-disconnected devices. If you want to locate the service you might have luck by making something answer for those ARP requests and then seeing what protocol the server attempts to use to communicate with the destination.

I wonder if you might be seeing this problem with some Broadcom drivers and ARP flooding, though your packet counts don't sound high enough to be the problem described in the forum.

Hi Evan, I agree that this dosen't seem to be an excessive amount of traffic and I agree that the PLC would best be on it's own network. The one issue with putting it on it's own network is that I have to wait 4 months until end of production to do so. The problem has only been effecting the PLC for the last 3 days, with it running no worries for at least the last 6 years - that's the bit that confuses me! — user1693454, Oct 03 '12 at 04:31
Maybe the problem is elsewhere - lots of testing going on at the moment and this was the one that jumped out at us - it could be those network cards, I will look at that too tomorrow. — user1693454, Oct 03 '12 at 06:12

Windows server sending constant ARP requests to offline devices

1 Answers1