vROps Alert: One or more ports on the Distributed Port Group are experiencing network contention due to dropped packets

Here is a vROps problem experienced by one of my customers:
Alert: One or more ports are experiencing network connection

(One or more ports on the Distributed Port Group are experiencing network contention due to dropped packets)

There was no evidence in vCenter that packets were being dropped.  The customer found KB2105109: VMware vRealize Operations Manager counters report false dropped packets on vSphere Distributed Switches with the alert: One or more ports are experiencing network contention

However, this seems to only apply to vROps 6.0.x and the customer is running the 6.2.x release.  An SR was opened and the support tech recommended the fix per KB2052917: vCenter Server 5.1/5.5/6.0 performance charts report dropped network packets

Okay great, so a patch needs to be applied to the ESXi 5.5 host.  The customer tried to applied the patch via VUM but it was marked obsoleted.  "Obsoleted" is an Update Manager compliance state.  As explained in the Installing and Administering VMware vSphere Update Manager documentation:

This compliance state applies mainly to patches. The target object has a newer version of the patch. For example, if a patch has multiple versions, after you apply the latest version to the host, the earlier versions of the patch are in Obsoleted By Host compliance state.


(https://pubs.vmware.com/vsphere-50/index.jsp?topic=%2Fcom.vmware.vsphere.update_manager.doc_50%2FGUID-EBAA4F4A-57E0-45ED-8730-4B851FC846A9.html)

Hmmm.... so the host has a newer version of the patch, so now what?

After some discussion we landed on the fact that the vCenter instance managing this host was likely the culprit as it has a patch level several versions behind the host.  I always recommend customers keep their vCenter and ESXi hosts at the same Update patch level.  Installing patches on hosts in-between major Updates is okay.  In this case, they were on different Update versions.

The vCenter instance was patched to the latest update and voila, the error disappeared from vROps.