?
Solved

Odd ARPs in capture

Posted on 2014-12-10
9
Medium Priority
?
632 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 2
  • 2
  • +2
9 Comments
 
LVL 30

Expert Comment

by:pgm554
ID: 40493102
You running a Vmware cluster?
0
 
LVL 22

Accepted Solution

by:
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.
0
 
LVL 30

Expert Comment

by:pgm554
ID: 40493189
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
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
LVL 62

Expert Comment

by:gheist
ID: 40493250
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
 

Author Comment

by:Brian
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.
0
 
LVL 62

Assisted Solution

by:gheist
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)
0
 
LVL 30

Expert Comment

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

Author Comment

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

Expert Comment

by:Member_2_7969424
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 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

Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I had an issue with InstallShield not being able to use Computer Browser service on Windows Server 2012. Here is the solution I found.
An article on effective troubleshooting
This video gives you a great overview about bandwidth monitoring with SNMP and WMI with our network monitoring solution PRTG Network Monitor (https://www.paessler.com/prtg). If you're looking for how to monitor bandwidth using netflow or packet s…
In this video we outline the Physical Segments view of NetCrunch network monitor. By following this brief how-to video, you will be able to learn how NetCrunch visualizes your network, how granular is the information collected, as well as where to f…

762 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