We have 2 VM's running on ESX 5.1. When I do a ping -A
, after a while I get every second ping as a DUP!
. When doing a normal ping
, I get 5 or 6 DUP!
s, and then it returns to normal.
Any ideas what to check?
If it return something like this:
1472 bytes from core-212-23-0-100.zen.net.uk (212.23.0.100): icmp_seq=1 ttl=121 time=28.9 ms
1472 bytes from core-212-23-0-100.zen.net.uk (212.23.0.100): icmp_seq=1 ttl=121 time=30.3 ms (DUP!)
There are multiple servers providing PING:We are running 6 hosts in this specific cluster (as you said) Each one (of your hosts) is responding to the ping packet, hence the dups. It's not something bad here.
To solve the problem you can see this link:
https://github.com/sasikanthbabu/Layer3Switch/issues/14
And as schaiba mentioned:
The man page says ping will report duplicate and damaged packets. Duplicate packets should never occur, and seem to be caused by inappropriate link-level retransmissions. Duplicates may occur in many situations and are rarely (if ever) a good sign, although the presence of low levels of duplicates may not always be cause for alarm
To resolve this issue, ensure that all virtual machine portgroups in the vSphere distributed switch are configured with IP hash with beaconing disabled.
Also, ensure that these settings are applied to any new portgroups that are created.
For more information, see the ESXi and vCenter Server 5.1 Documentation.
Changing beacon probing to link status on all port groups was the critical component in getting DUP! to stop. This also corrected many other strange network happenings within our environment. Never could pin down these strange happenings until we added more hosts, then VMs started losing connections. This is what drove us down to this setting.
ping will report duplicate and damaged packets. Duplicate packets should never occur, and seem to be caused by inappropriate link-level retransmissions. Duplicates may occur in many situations and are rarely (if ever) a good sign, although the presence of low levels of duplicates may not always be cause for alarm
– schaiba Jul 23 '14 at 13:08