Solved

Odd ARPs in capture

Posted on 2014-12-10
9
516 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
ID: 40493102
You running a Vmware cluster?
0
 
LVL 22

Accepted Solution

by:
eeRoot earned 250 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
DevOps Toolchain Recommendations

Read this Gartner Research Note and discover how your IT organization can automate and optimize DevOps processes using a toolchain architecture.

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

3 Use Cases for Connected Systems

Our Dev teams are like yours. They’re continually cranking out code for new features/bugs fixes, testing, deploying, testing some more, responding to production monitoring events and more. It’s complex. So, we thought you’d like to see what’s working for us.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
ASA Troubleshooting: Easy way to determine an interface's next hop 18 72
Skype for Business video calls drops 2 58
eigrp routing loop 5 39
Switch ports not working 8 32
Use of TCL script on Cisco devices:  - create file and merge it with running configuration to apply configuration changes
In this article, I am going to show you how to simulate a multi-site Lab environment on a single Hyper-V host. I use this method successfully in my own lab to simulate three fully routed global AD Sites on a Windows 10 Hyper-V host.
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 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…

786 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