Odd ARPs in capture

Posted on 2014-12-10
Medium Priority
Last Modified: 2016-07-26
We were having some network issues and in the course of doing a Wireshark Capture, I caught a few ARPs that raised my eyebrow.
We use 10.1.x.x addressing on our network and the packets that caught my attention were ARPs from machines saying they were  Strangely, an ipconfig on the machine produces a 10.1.x.x address and a Wireshark capture ran on the offending machines produces no ARPs with the address; I only see it on captures done from other machines.  Multiple machines are ARPing claiming to be, but ipconfig, ping, nslookup, and our network scanner all say otherwise.  I am also getting SNMP trap packets in the capture.  
The machines that I have found in the capture are all the same make and model.  None of these machines are displaying connectivity problems to my knowledge.  Because they are coming from the same Make/Model, I’m thinking that it’s a NIC issue, maybe driver related.  I am not the network manager, but I thought it was odd and I’m looking for some input.  Sample of the captures are below.

0.000000000      Elitegro_90:02:98      Vmware_a8:b0:5b      ARP      60 is at ec:a8:6b:90:02:98
0.000001000      Elitegro_90:93:71      Vmware_a8:b0:5b      ARP      60 is at ec:a8:6b:90:93:71
Duplicate IP address detected for (ec:a8:6b:90:93:71) - also in use by ec:a8:6b:90:02:98 (frame 1)

0.000002000      Elitegro_94:99:43      Vmware_a8:b0:5b       ARP      60 is at ec:a8:6b:94:99:43
0.000002000      Elitegro_90:03:1a      Vmware_a8:b0:5b       ARP      60 is at ec:a8:6b:90:03:1a
0.000002000      Elitegro_90:02:5a      Vmware_a8:b0:5b       ARP      60 is at ec:a8:6b:90:02:5a
0.000003000      Elitegro_90:03:bc      Vmware_a8:b0:5b       ARP      60 is at ec:a8:6b:90:03:bc

0.246478000      SNMP      154      trap iso.
0.451490000      SNMP      154      trap iso.
Ethernet II, Src: Elitegro_94:6f:69 (ec:a8:6b:94:6f:69), Dst: Elitegro_fa:cc:46 (74:27:ea:fa:cc:46)
Internet Protocol Version 4, Src: (, Dst: (

0.667489000      SNMP      154      trap iso.
Question by:Brian
  • 3
  • 2
  • 2
  • +2
LVL 30

Expert Comment

ID: 40493102
You running a Vmware cluster?
LVL 22

Accepted Solution

eeRoot earned 500 total points
ID: 40493134
The MAC OUI points to the sysboard manufacturer "Elitegroup computer Systems"  Do you have any custom built PC's in your environment?  Try tracing down the MAC's that start with ec:a8:6b.  That should, at least, get you to the specific system you need to check.  Perhaps there is a PC with a second NIC connected to the network.
LVL 30

Expert Comment

ID: 40493189
Looks like you got a MAC conflict with the Vmware virtual adapter

7 new features that'll make your work life better

It’s our mission to create a product that solves the huge challenges you face at work every day. In case you missed it, here are 7 delightful things we've added recently to monday to make it even more awesome.

LVL 62

Expert Comment

ID: 40493250
                          NO. 239, Sec. 2, Ti Ding Blvd.
                        Taipei  11493

Could be IP conflict on VoIP phones?
no MAC is from vmware.

You can run arpwatch on subnet to see if there are more misconfigured devices.

Author Comment

ID: 40493620
I'm not running a Vm cluster, the PC I ran the capture from was running a single VM I use for testing software.  The Elitegroup MACs are all from same make/model PC, Veriton M2610, and right now my best guess is a driver issue.  I'm working on one of the machines right now and will update; was looking for possible alternate explanations because I just don't quite understand how a NIC can ARP an address, one that doesn't or shouldn't exist on our network, and yet it doesn't show as having that address when you check it at the machine.
LVL 62

Assisted Solution

gheist earned 500 total points
ID: 40493687
It happens when you restart DHCP server sometimes.
You need to hunt those MACs to network port and force DHCP refresh on them (or adjust IPs if no DHCP involved)
LVL 30

Expert Comment

ID: 40494514
Just a thought,but you do have 2 NIC's in any machine that is running Vmware as the 2nd one is a virtual NIC which has the 192 address instead of the 10 which you are assigning to the hardware NIC.

Disable the virtual NIC and run another capture and my guess is those ARP's will go away.

Author Comment

ID: 40500300
Thank you  for the suggestions, haven't figured it out yet, but I will employ the suggestions I received here and update when I get it.  I've captured the ARPs several times with different machines, it was just that once that I did it from my PC while running a virtual machine.  Correct drivers are installed, so it's not a driver issue.  Next step is to do a clean install, thinking maybe it's a "bad" image because every machine was created using the same image.

Expert Comment

ID: 41730464
Hi All,  I know this is an old post, I just stumbled across it searching for something else.  We have a customer that uses and they have a server on  Every time we reboot server it cant get it's ip back because it says there is an IP conflict and it is in use.

To cut to the chase the culprit is Acer workstations, which have ASF enabled in the BIOS using  Disabling ASF in the BIOS resolves the issue.

This is potentially the source of the ARPs you are seeing here as well.

Featured Post

The 14th Annual Expert Award Winners

The results are in! Meet the top members of our 2017 Expert Awards. Congratulations to all who qualified!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

This article is in regards to the Cisco QSFP-4SFP10G-CU1M cables, which are designed to uplink/downlink 40GB ports to 10GB SFP ports. I recently experienced this and found very little configuration documentation on how these are supposed to be confi…
This article will show you step-by-step instructions to build your own NTP CentOS server.  The network diagram shows the best practice to setup the NTP server farm for redundancy.  This article also serves as your NTP server documentation.
Michael from AdRem Software outlines event notifications and Automatic Corrective Actions in network monitoring. Automatic Corrective Actions are scripts, which can automatically run upon discovery of a certain undesirable condition in your network.…
Michael from AdRem Software explains how to view the most utilized and worst performing nodes in your network, by accessing the Top Charts view in NetCrunch network monitor (https://www.adremsoft.com/). Top Charts is a view in which you can set seve…

607 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question