Forum Discussion

Michael_Dieter's avatar
9 years ago

Source of ESX PacketsDroppedRx ?

I've recently discovered a few ESX hosts (ESXi 5.5.0) in order to evaluate whether or not to discover and monitor our entire ESX environment.  Since day 1, both have been in yellow error condition for the datapoint "PacketsDroppedRx" under the ESX Host datasource (rate fluctuates between 25k and 125k per second).  However, for datapoint "DroppedRx" under ESX Host Interface, the total indicated rate for ALL vmnic instances is always less than 10k per second, and unfortunately there is not a corresponding "DroppedRx" datapoint under each instance of ESX Virtual Machines (there is a PacketsTx and PacketsRx for each Virtual Machine but not one for drops).

  1. Strangely, our ESX Admin can find no indication of this "PacketsDroppedRx" value in vSphere anywhere and he is not aware of an ongoing degradation of service that might be expected due to excessive dropped packets.  So I have 2 questions:
  • 1)does anyone know to what "PacketsDroppedRx" can be attributed, or at least where to look under the ESX hood to find it?
  • 2)does anyone know why there is not a direct relationship between "DroppedRx" on vmnics and "PacketsDroppedRx" on a host? -- I would expect that the sum of the each individual vmnic "DroppedRx" would equal the value of "PacketsDroppedRx" for that host.

2 Replies

Replies have been turned off for this discussion
  • I forgot to post that I discovered this appears to be a known issue for multiple ESX releases; one that is only cosmetic.  
    Its interesting that a patch containing the fix was documented as of October 2015 for multiple pre-6.0 ESX releases, but while there have been 4 ESX updates to 6.0 since that time (including 3 so far in 2016) not one of them has included a fix.

    https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2052917

  • I also subsequently learned that the indicated patch for ESX 5.5 has been applied to our environment, and does not appear to have resolved the symptom.  Given that the issue is cosmetic and not service-impacting its unlikely our VMWare team will be spending effort to fix it.