VMware Communities
iamdaboss
Contributor
Contributor

Duplicate packets with ping on guest OS(Linux)

Hi,

I am getting lot of duplicate packets when i ping to an IP (router, host system or an internet server) from my guest OS.

Any pointers with this regard would be greatly helpful.

I have the following configuration:

VMware Workstation 6.0.0 build-45731

Host OS: Windows XP SP2 (32bit)

Guest OS: Fedora Core 6 - 32bit (Zod - Kernel ver: 2.6.18-1.2798.fc6)

I have bridged VMnet0 to the 'Wireless Connection' on the Host OS.

\## Host OS ##

\## ipconfig /all ##

Windows IP Configuration

Host Name . . . . . . . . . . . . : homePC

Primary Dns Suffix . . . . . . . :

Node Type . . . . . . . . . . . . : Unknown

IP Routing Enabled. . . . . . . . : Yes

WINS Proxy Enabled. . . . . . . . : Yes

DNS Suffix Search List. . . . . . : xyz.edu

xyz.edu

Ethernet adapter VMware Network Adapter VMnet8:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet8

Physical Address. . . . . . . . . : 00-50-56-C0-00-08

Dhcp Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 192.168.93.1

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . :

Ethernet adapter VMware Network Adapter VMnet1:

Connection-specific DNS Suffix . :

Description . . . . . . . . . . . : VMware Virtual Ethernet Adapter for VMnet1

Physical Address. . . . . . . . . : 00-50-56-C0-00-01

Dhcp Enabled. . . . . . . . . . . : No

IP Address. . . . . . . . . . . . : 192.168.157.1

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . :

Ethernet adapter Wireless Network Connection:

Connection-specific DNS Suffix . : xyz.edu

Description . . . . . . . . . . . : Intel(R) PRO/Wireless LAN 2100 3B Mini PCI Adapter

Physical Address. . . . . . . . . : 00-0C-F1-3C-99-C7

Dhcp Enabled. . . . . . . . . . . : Yes

Autoconfiguration Enabled . . . . : Yes

IP Address. . . . . . . . . . . . : 192.168.15.101

Subnet Mask . . . . . . . . . . . : 255.255.255.0

Default Gateway . . . . . . . . . : 192.168.15.1

DHCP Server . . . . . . . . . . . : 192.168.15.1

DNS Servers . . . . . . . . . . . : 192.168.15.1

Lease Obtained. . . . . . . . . . : Wednesday, September 12, 2007 4:19:54 PM

Lease Expires . . . . . . . . . . : Thursday, September 13, 2007 4:19:54 PM

\## VMX file: ##

config.version = "8"

virtualHW.version = "6"

scsi0.present = "TRUE"

scsi0.virtualDev = "lsilogic"

memsize = "400"

ide0:0.present = "TRUE"

ide0:0.fileName = "Other Linux 2.6.x kernel.vmdk"

ide0:0.deviceType = "rawDisk"

ide1:0.present = "TRUE"

ide1:0.fileName = "auto detect"

ide1:0.deviceType = "cdrom-raw"

floppy0.autodetect = "TRUE"

ethernet0.present = "TRUE"

ethernet0.wakeOnPcktRcv = "FALSE"

usb.present = "TRUE"

ehci.present = "TRUE"

sound.present = "TRUE"

sound.fileName = "-1"

sound.autodetect = "TRUE"

svga.autodetect = "TRUE"

pciBridge0.present = "TRUE"

mks.keyboardFilter = "allow"

displayName = "FedoraCore6"

guestOS = "other26xlinux"

nvram = "Other Linux 2.6.x kernel.nvram"

deploymentPlatform = "windows"

virtualHW.productCompatibility = "hosted"

tools.upgrade.policy = "useGlobal"

ide1:0.autodetect = "TRUE"

floppy0.startConnected = "FALSE"

floppy0.fileName = "A:"

isolation.tools.hgfs.disable = "TRUE"

ide1:0.startConnected = "TRUE"

ethernet0.addressType = "generated"

uuid.location = "56 4d 5e 41 94 bb 63 f6-84 09 ef 88 ec fe ce cd"

uuid.bios = "56 4d 5e 41 94 bb 63 f6-84 09 ef 88 ec fe ce cd"

ide0:0.redo = ""

pciBridge0.pciSlotNumber = "17"

scsi0.pciSlotNumber = "16"

ethernet0.pciSlotNumber = "32"

sound.pciSlotNumber = "33"

ehci.pciSlotNumber = "34"

ethernet0.generatedAddress = "00:0c:29:fe:ce:cd"

ethernet0.generatedAddressOffset = "0"

tools.syncTime = "FALSE"

checkpoint.vmState = ""

\## Guest OS ##

\[root@localhost ~]# ifconfig -a

eth0 Link encap:Ethernet HWaddr 00:0C:29:FE:CE:CD

inet addr:192.168.15.103 Bcast:192.168.15.255 Mask:255.255.255.0

inet6 addr: fe80::20c:29ff:fefe:cecd/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1

RX packets:324 errors:0 dropped:0 overruns:0 frame:0

TX packets:80 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:43943 (42.9 KiB) TX bytes:14055 (13.7 KiB)

Interrupt:169 Base address:0x2024

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0

inet6 addr: ::1/128 Scope:Host

UP LOOPBACK RUNNING MTU:16436 Metric:1

RX packets:3510 errors:0 dropped:0 overruns:0 frame:0

TX packets:3510 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:5844724 (5.5 MiB) TX bytes:5844724 (5.5 MiB)

sit0 Link encap:IPv6-in-IPv4

NOARP MTU:1480 Metric:1

RX packets:0 errors:0 dropped:0 overruns:0 frame:0

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

\[root@localhost ~]# ping www.yahoo.com

PING www.yahoo.com (69.147.114.210) 56(84) bytes of data.

64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=56 time=50.7 ms

64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=55 time=56.6 ms (DUP!)

64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=54 time=58.6 ms (DUP!)

64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=53 time=68.6 ms (DUP!)

64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=52 time=68.6 ms (DUP!)

64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=51 time=80.6 ms (DUP!)

64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=50 time=186 ms (DUP!)

64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=49 time=355 ms (DUP!)

64 bytes from www.yahoo.com (69.147.114.210): icmp_seq=1 ttl=48 time=504 ms (DUP!)

\--- www.yahoo.com ping statistics ---

1 packets transmitted, 1 received, +8 duplicates, 0% packet loss, time 0ms

rtt min/avg/max/mdev = 50.705/159.022/504.678/154.117 ms

-


Reply
0 Kudos
21 Replies
AWo
Immortal
Immortal

That happens

\- if you ping a broadcast address, because you send one ping and get many answers back.

\- if two or more systems have the same IP and both send an answer back.

\- if your NIC is in promiscious mode and you have a not so smart switch (or hub) which sends the ping also back to the pinging system.

AWo

Message was edited by:

AWo

vExpert 2009/10/11 [:o]===[o:] [: ]o=o[ :] = Save forests! rent firewood! =
Reply
0 Kudos
iamdaboss
Contributor
Contributor

The problem I later figured out was because i have bridged VMnet0 to the Wireless Connection on the Host OS. I believe that caused the problem (may be because it had a WEP key).

Later I bridged VMnet0 to the wired connection. It works find now.

Thank you for all who responded.

Reply
0 Kudos
sveronese
Contributor
Contributor

Hi! There is a solution to this problem? I have the same problem with a vmnet interface bridged with a wireless Intel ipw3945 without any protection to the wireless network (no wep, no mac control).

Thanks,

Simone

Reply
0 Kudos
nullnil
Contributor
Contributor

I'm bridging via Intel 3945ABG Wireless NIC, and got dup ping response.

after looking at the traffic captured by WireShark, I see the following things (with MAC OUI):

(1) 192.168.0.21 => 192.168.0.1 ICMP Echo (ping) request (seq = 1)

(2) 192.168.0.1 => 192.168.0.121 ICMP Echo (ping) reply (seq = 1)

(3) 192.168.0.1 => 192.168.0.121 ICMP Echo (ping) reply (seq = 1)

it seems to be a problem in Wireless NIC driver (the third packet has the same Src MAC and Dst MAC).

Reply
0 Kudos
nullnil
Contributor
Contributor

sorry, seems not the problem of Intel Wireless NIC.

The expected behavior is:

(1) 192.168.0.21 VMware => 192.168.0.1 D-Link ICMP Echo (ping) request (seq = 1)

(2) 192.168.0.1 D-Link => 192.168.0.121 InterCor ICMP Echo (ping) reply (seq = 1)

(3) 192.168.0.1 InterCor => 192.168.0.121 VMware ICMP Echo (ping) reply (seq = 1)

The following links are talking about the similar problem:

http://communities.vmware.com/thread/120356

http://communities.vmware.com/thread/138858

http://communities.vmware.com/thread/176249

I'll update this thread as I got something new.

Reply
0 Kudos
itsgnd
Contributor
Contributor

I have been having the same problem. I am using VMWare player 3.1.3

build-324285 running a Ubuntu client on a Windows 7 host. I have tried

several means of trying to determine what exactly the problem is and

have found this:

Environment:

1 - Ubuntu guest running in the above configuration (192.168.0.105), called server A, MAC address 40:00:00:00:00:01

1 - Physical Ubuntu server (192.168.0.107), called server B , MAC address 00:02:b3:f0:b7:51

1 - Physical Windows 7 VMWare Player host machine, MAC address 90:e6:ba:80:07:f4

Both physcal servers are on the same physical switch and VMWare is set up for bridging.

Procedure:

Initiate one ping packet from server A (example: ping -c 1 192.168.0.107) to server B

Capture all ICMP traffic on the ethernet interface using tcpdump (example: tcpdump -w capture.cap icmp)

Results from Wireshark analysis:

Time

Prot.

Source

Src MAC

Destination

Dst MAC

Info

0.00000

ICMP

192.168.0.105

90:e6:ba:80:07:f4

192.168.0.107

00:02:b3:f0:b7:51

Echo (ping) request

0.00002

ICMP

192.168.0.107

00:02:b3:f0:b7:51

192.168.0.105

40:00:00:00:00:01

Echo (ping) reply

0.00002

ICMP

192.168.0.105

40:00:00:00:00:01

192.168.0.107

00:02:b3:f0:b7:51

Echo (ping) request

0.00003

ICMP

192.168.0.107

00:02:b3:f0:b7:51

192.168.0.105

40:00:00:00:00:01

Echo (ping) reply

0.00019

ICMP

192.168.0.102

90:e6:ba:80:07:f4

192.168.0.107

00:02:b3:f0:b7:51

Redirect (Redirect for network)

    • I did validate that this pattern continues if two or more consecutive pings are initiated as well.

    • In the 1st packet the Source MAC address should be 40:00:00:00:00:01Analysis:

It appears that somehow the host machine is duplicating the ping request

thereby doubling the amount of ping replies. In addition it is causing

the host to send an ICMP redirect further polluting the network with

unnecessary traffic. Somewhere the packet is getting duplicated, I

believe the most likely candidate is the windows IP stack (or maybe

within the routing engine) or a bug in the VMWare driver. It is

interesting to note that the incorrect packet is sent first.

The redirect seems to be an effect of the duplicate packet (the 1st ping

request) and the fact that it is not originating from the appropriate

MAC address associated to 192.168.0.105 in the arp table on the vmware

host thereby looking like an inefficiently routed packet.

Any thoughts as to how to get Windows/VMWare to stop duplicating the

packet? The redirect is a symptom, not the cause. I have disabled

redirects in the registry and filtered them out with firewall rules, but

the best that is achieved is that the redirect packet is eliminated.

The duplicate packets still occur.

Reply
0 Kudos
continuum
Immortal
Immortal

how many physical nics does your host have ?

how did you configure the vmnet-bridge ?

did you disable automatic-bridging ?




_________________________

VMX-parameters- WS FAQ -[ MOAcd|http://sanbarrow.com/moa241.html] - VMDK-Handbook


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
itsgnd
Contributor
Contributor

Each device has one physical NIC.

Bridging is setup however the default settings are set up. The VMWare player doesn't give you too many options for configuration. Is there a file that contains settings you can manually modify?

Reply
0 Kudos
continuum
Immortal
Immortal

I see - looks you have not yet extracted the vmnetcfg.exe tool.

before you have not disabled automatic-bridging troubleshooting bridge problems is moot




_________________________

VMX-parameters- WS FAQ -[ MOAcd|http://sanbarrow.com/moa241.html] - VMDK-Handbook


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
itsgnd
Contributor
Contributor

Ok, I found that you can check the configuration of the vmnet0 bridging interface with a utility called vmnetcfg. I found that my installation did not have the executable. I found the procedure below to add the command.

To extract vmnetcfg.exe from the installer do the following:

1. Run the installer with /e option. For example:

VMware-player-3.0.0-197124.exe /e .\extract

Contents will be extracted to “extract” folder.

2. Open “network.cab” and copy vmnetcfg.exe to your installation folder,

typically “C:\Program Files\VMware\VMware Player\”.

After I extracted the executable I ran it and manually bound only the physical adapter to vmnet0. Unfortunately this did not change anything. I also disabled vmnet1 and vmnet8. This also did not affect the behaviour.

Any other thoughts?

Reply
0 Kudos
itsgnd
Contributor
Contributor

Looks like a lot of good info in those links. I'll definately be spending some time looking through them. Thanks!

Reply
0 Kudos
itsgnd
Contributor
Contributor

FYI My .vmx file:

#!/usr/bin/vmware

.encoding = "windows-1252"

tools.statusMsgs.disable = "TRUE"

virtualHW.version = "4"

ide0:0.autodetect = "TRUE"

tools.syncTime = "TRUE"

nvram = "appliance.nvram"

ide0:0.present = "TRUE"

config.version = "8"

ide0:0.fileName = "auto detect"

ide0:0.startConnected = "FALSE"

ide0:0.deviceType = "cdrom-raw"

MemAllowAutoScaleDown = "FALSE"

tools.remindInstall = "FALSE"

uuid.action = "create"

displayName = "OpenVPN AS - config 2"

guestOS = "ubuntu"

vix.inGuest.enable="TRUE"

scsi0.present = "TRUE"

scsi0.virtualDev = "lsilogic"

scsi0:0.fileName = "system.vmdk"

scsi0:0.present = "TRUE"

memsize = "512"

ethernet0.present = "TRUE"

ethernet0.addressType = "generated"

ethernet0.connectionType = "bridged"

scsi0:0.redo = ""

ethernet0.generatedAddress = "00:0c:29:d3:b1:59"

uuid.location = "56 4d 99 eb 12 62 71 9a-8d 47 bb d1 bd d3 b1 59"

uuid.bios = "56 4d 99 eb 12 62 71 9a-8d 47 bb d1 bd d3 b1 59"

priority.grabbed = "normal"

priority.ungrabbed = "normal"

ethernet0.generatedAddressOffset = "0"

extendedConfigFile = "OpenVPN-AS-Appliance.vmxf"

virtualHW.productCompatibility = "hosted"

cleanShutdown = "FALSE"

replay.supported = "FALSE"

replay.filename = ""

vmotion.checkpointFBSize = "16777216"

sound.present = "FALSE"

usb.present = "FALSE"

floppy0.present = "FALSE"

checkpoint.vmState = "OpenVPN-AS-Appliance.vmss"

ethernet0.linkStatePropagation.enable = "TRUE"

Reply
0 Kudos
continuum
Immortal
Immortal

installation of WS 7.1.3 on win7 can go wrong in many ways

please walk through my notes - http://faq.sanbarrow.com/index.php?solution_id=1113

there I have a section "how to verify correct installation of drivers" also check the services

I just see you use virtual hardware type 4 - that may also play into this game - do you need such old version ???




_________________________

VMX-parameters- WS FAQ -[ MOAcd|http://sanbarrow.com/moa241.html] - VMDK-Handbook


________________________________________________
Do you need support with a VMFS recovery problem ? - send a message via skype "sanbarrow"
I do not support Workstation 16 at this time ...

Reply
0 Kudos
itsgnd
Contributor
Contributor

Ok, I have validated the registry keys in your document and I do only have the test key with the dword value of 0. So something apparently did not setup correctly.

I am not sure what determines the Hardware level, is it just safe to change it to another number? If so, what do you recommend?

I'll try your procedure to do a clean install and let you know what happens.

Thanks for your help.

Reply
0 Kudos
itsgnd
Contributor
Contributor

Oops, I didn't expand under adapters, I do indeed have adapters defined. Here is what is in the registry:

"VMnet"=dword:00000000

"VMnet"=dword:ffffffff

"VMnet"=dword:ffffffff

After seeing this I was poking around in the other parameters and found these multi string entries. The Route string is what caught my eye:

"Bind"=hex(7):5c,00,44,00,65,00,76,00,69,00,63,00,65,00,5c,00,7b,00,35,00,39,\

00,35,00,44,00,43,00,34,00,37,00,33,00,2d,00,34,00,30,00,45,00,33,00,2d,00,\

34,00,34,00,30,00,31,00,2d,00,41,00,34,00,39,00,31,00,2d,00,35,00,37,00,33,\

00,46,00,35,00,39,00,33,00,30,00,31,00,38,00,38,00,35,00,7d,00,00,00,5c,00,\

44,00,65,00,76,00,69,00,63,00,65,00,5c,00,7b,00,46,00,39,00,37,00,39,00,31,\

00,30,00,32,00,33,00,2d,00,34,00,33,00,37,00,38,00,2d,00,34,00,45,00,32,00,\

46,00,2d,00,41,00,35,00,34,00,31,00,2d,00,37,00,43,00,32,00,35,00,45,00,39,\

00,37,00,37,00,39,00,33,00,32,00,43,00,7d,00,00,00,5c,00,44,00,65,00,76,00,\

69,00,63,00,65,00,5c,00,7b,00,44,00,41,00,42,00,39,00,38,00,41,00,41,00,45,\

00,2d,00,35,00,42,00,30,00,46,00,2d,00,34,00,44,00,31,00,33,00,2d,00,38,00,\

30,00,36,00,31,00,2d,00,37,00,38,00,46,00,33,00,41,00,32,00,32,00,38,00,37,\

00,39,00,39,00,46,00,7d,00,00,00,00,00

"Route"=hex(7):22,00,7b,00,35,00,39,00,35,00,44,00,43,00,34,00,37,00,33,00,2d,\

00,34,00,30,00,45,00,33,00,2d,00,34,00,34,00,30,00,31,00,2d,00,41,00,34,00,\

39,00,31,00,2d,00,35,00,37,00,33,00,46,00,35,00,39,00,33,00,30,00,31,00,38,\

00,38,00,35,00,7d,00,22,00,00,00,22,00,7b,00,46,00,39,00,37,00,39,00,31,00,\

30,00,32,00,33,00,2d,00,34,00,33,00,37,00,38,00,2d,00,34,00,45,00,32,00,46,\

00,2d,00,41,00,35,00,34,00,31,00,2d,00,37,00,43,00,32,00,35,00,45,00,39,00,\

37,00,37,00,39,00,33,00,32,00,43,00,7d,00,22,00,00,00,22,00,7b,00,44,00,41,\

00,42,00,39,00,38,00,41,00,41,00,45,00,2d,00,35,00,42,00,30,00,46,00,2d,00,\

34,00,44,00,31,00,33,00,2d,00,38,00,30,00,36,00,31,00,2d,00,37,00,38,00,46,\

00,33,00,41,00,32,00,32,00,38,00,37,00,39,00,39,00,46,00,7d,00,22,00,00,00,\

00,00

"Export"=hex(7):5c,00,44,00,65,00,76,00,69,00,63,00,65,00,5c,00,56,00,4d,00,6e,\

00,65,00,74,00,42,00,72,00,69,00,64,00,67,00,65,00,5f,00,7b,00,35,00,39,00,\

35,00,44,00,43,00,34,00,37,00,33,00,2d,00,34,00,30,00,45,00,33,00,2d,00,34,\

00,34,00,30,00,31,00,2d,00,41,00,34,00,39,00,31,00,2d,00,35,00,37,00,33,00,\

46,00,35,00,39,00,33,00,30,00,31,00,38,00,38,00,35,00,7d,00,00,00,5c,00,44,\

00,65,00,76,00,69,00,63,00,65,00,5c,00,56,00,4d,00,6e,00,65,00,74,00,42,00,\

72,00,69,00,64,00,67,00,65,00,5f,00,7b,00,46,00,39,00,37,00,39,00,31,00,30,\

00,32,00,33,00,2d,00,34,00,33,00,37,00,38,00,2d,00,34,00,45,00,32,00,46,00,\

2d,00,41,00,35,00,34,00,31,00,2d,00,37,00,43,00,32,00,35,00,45,00,39,00,37,\

00,37,00,39,00,33,00,32,00,43,00,7d,00,00,00,5c,00,44,00,65,00,76,00,69,00,\

63,00,65,00,5c,00,56,00,4d,00,6e,00,65,00,74,00,42,00,72,00,69,00,64,00,67,\

00,65,00,5f,00,7b,00,44,00,41,00,42,00,39,00,38,00,41,00,41,00,45,00,2d,00,\

35,00,42,00,30,00,46,00,2d,00,34,00,44,00,31,00,33,00,2d,00,38,00,30,00,36,\

00,31,00,2d,00,37,00,38,00,46,00,33,00,41,00,32,00,32,00,38,00,37,00,39,00,\

39,00,46,00,7d,00,00,00,00,00

Translated to ascii each multi string is:

"{595DC473-40E3-4401-A491-573F59301885}"

"{F9791023-4378-4E2F-A541-7C25E977932C}"

"{DAB98AAE-5B0F-4D13-8061-78F3A228799F}"

This made me notice that the bridged interface was being routed. I removed the "{595DC473-40E3-4401-A491-573F59301885}" entry and voila, no more duplicate packets.

Thank you ever so much for your help. Without it I would never have made it this far.

This would appear to be a bug with VMWare, what is the best way to report something like this without having a service contract? From other posts I've seen I'm not the only one that has had this issue.

Reply
0 Kudos
kuzeyka
Contributor
Contributor

I was annoyed by these (DUP!) pings, googling found that the culprit on a Windows 7 host is a service called "Routing and Remote Access". Stopping and disabling it immediately ceased duped pings on all running machines.

I was afraid it would affect Remote Desktop (RDP mstsc.exe) connectivity but it didn't, host machine is still well available over RDP.

I was trying juggling vm adapters which was of no use and dupe pings were showing up even in Player 6.1 and Workstation 10 (the latest available today)

Reply
0 Kudos
shinrich56
Contributor
Contributor

I've spent a couple days tracking this down on my system.   This has been an issue on this system for quite some time, but I've been able to work around it up until now.  One system (my main system) was showing the ICMP redirects and the packet traces for ICMP (and TCP) traffic made it look like the host OS (windows 7 in my case) was routing the bridged traffic as reported by itsgnd.  The other three vmware installs I tested were fine.  The "Routing and Remote Access" service was already disabled.

I ended up following step five in VMware KB: Troubleshooting network connection failures  to reinstall the vmware bridge service on the host box.  That seems to have done the trick.  I had uninstalled vmware 7 and installed vmware workstation 10, but that didn't fix things.  Evidently that unintall and reinstall does not reinstall the vmware bridge service (which seems odd).

Reply
0 Kudos
AeroAmD
Contributor
Contributor

SO I FOUND THE SOLUTION.

I'm using a MAC and My Internet sharing was on . THats through system preferece and sharing. Once i switched off sharing it fixed the DUP! ping issue.

I'm assuming it would be something similar in Windows 7 like ICS Internet Connection Sharing or Routing and Remote Access

Reply
0 Kudos
ITP1
Contributor
Contributor

Spoiler
Check the corresponding vswitch load balancing setting.

In my case is was on "Route Based on IP Hash" and after changing this to "Route Based on Originating Port" Problem was solved.

Reply
0 Kudos