Solved

Odd ARPs in capture

Posted on 2014-12-10
9
452 Views
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 192.168.0.10.  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 192.168.0.10 address; I only see it on captures done from other machines.  Multiple machines are ARPing claiming to be 192.168.0.10, 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      192.168.0.10 is at ec:a8:6b:90:02:98
0.000001000      Elitegro_90:93:71      Vmware_a8:b0:5b      ARP      60      192.168.0.10 is at ec:a8:6b:90:93:71
Duplicate IP address detected for 192.168.0.10 (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      192.168.0.10 is at ec:a8:6b:94:99:43
0.000002000      Elitegro_90:03:1a      Vmware_a8:b0:5b       ARP      60      192.168.0.10 is at ec:a8:6b:90:03:1a
0.000002000      Elitegro_90:02:5a      Vmware_a8:b0:5b       ARP      60      192.168.0.10 is at ec:a8:6b:90:02:5a
0.000003000      Elitegro_90:03:bc      Vmware_a8:b0:5b       ARP      60      192.168.0.10 is at ec:a8:6b:90:03:bc

0.246478000      192.168.0.10      192.168.0.10      SNMP      154      trap iso.3.6.1.4.1.3183.1.1 1.3.6.1.4.1.3183.1.1.1
0.451490000      192.168.0.10      192.168.0.10      SNMP      154      trap iso.3.6.1.4.1.3183.1.1 1.3.6.1.4.1.3183.1.1.1
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: 192.168.0.10 (192.168.0.10), Dst: 192.168.0.10 (192.168.0.10)


0.667489000      192.168.0.10      192.168.0.10      SNMP      154      trap iso.3.6.1.4.1.3183.1.1 1.3.6.1.4.1.3183.1.1.1
0
Comment
Question by:Brian
  • 3
  • 2
  • 2
  • +2
9 Comments
 
LVL 30

Expert Comment

by:pgm554
Comment Utility
You running a Vmware cluster?
0
 
LVL 21

Accepted Solution

by:
eeRoot earned 250 total points
Comment Utility
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.
0
 
LVL 30

Expert Comment

by:pgm554
Comment Utility
Looks like you got a MAC conflict with the Vmware virtual adapter

See:
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=219
0
 
LVL 61

Expert Comment

by:gheist
Comment Utility
ELITEGROUP COMPUTER SYSTEMS CO., LTD.
                          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 192.168.0.1/?? subnet to see if there are more misconfigured devices.
0
How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

 

Author Comment

by:Brian
Comment Utility
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.
0
 
LVL 61

Assisted Solution

by:gheist
gheist earned 250 total points
Comment Utility
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)
0
 
LVL 30

Expert Comment

by:pgm554
Comment Utility
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.
0
 

Author Comment

by:Brian
Comment Utility
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.
0
 

Expert Comment

by:Member_2_7969424
Comment Utility
Hi All,  I know this is an old post, I just stumbled across it searching for something else.  We have a customer that uses 192.168.0.0/24 and they have a server on 192.168.0.10.  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 192.168.0.10.  Disabling ASF in the BIOS resolves the issue.

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

Featured Post

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

#Citrix #Citrix Netscaler #HTTP Compression #Load Balance
Even if you have implemented a Mobile Device Management solution company wide, it is a good idea to make sure you are taking into account all of the major risks to your electronic protected health information (ePHI).
Get a first impression of how PRTG looks and learn how it works.   This video is a short introduction to PRTG, as an initial overview or as a quick start for new PRTG users.
In this tutorial you'll learn about bandwidth monitoring with flows and packet sniffing with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're interested in additional methods for monitoring bandwidt…

771 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

Need Help in Real-Time?

Connect with top rated Experts

10 Experts available now in Live!

Get 1:1 Help Now