From time to time, Spectrum the cached SNMPv3 profile data gets out of synchronization with the actual device that Spectrum is polling. When this happens, it causes false "Management Agent Lost" alarms in Spectrum, even though Spectrum is using the correct Authentication credentials. Normally running a reset on the SNMPv3 Authentication data corrects the issue, but since upgrading to Spectrum 10.2.x we have noticed the reset fails to update the SNMPv3 cache.
In order for Spectrum to successfully poll a device using SNMPv3, we must match the msgAuthoritativeEngineID, the msgAuthoritativeEngineBoots, and the msgAuthoritativeEngineTime records. If these records match and we are using the correct authentication and privacy credentials/algorithms, then we can successfully communicate to the device.
However, if any of these records are out of sync, then the SNMPv3 requests will fail with a PDU reporting back why the request failed. Normally we will see a report of PDU 18.104.22.168.22.214.171.124.1.2.0 (usmStatsNotInTimeWindows), indicating the authoritative engine's boot count or engine time are out of sync, causing the request to fail.
When this happens, a common solution was to initiate a reset in Spectrum, to dump the cached data and do a fresh poll, to get the SNMPv3 profile data in sync with the device. But this reset was not working in Spectrum 10.1.2 and Spectrum 10.2.x.
Engineering found a defect with the SNMPv3 Authentication reset code, which caused the reset to fail without error. This defect is addressed in Spectrum_10.02.01.PTF_10.2.121.
If you are using SNMPv3, and running Spectrum 10.1.x or Spectrum 10.2.x, CA recommends upgrading to Spectrum 10.2.1, and applying the Spectrum_10.02.02.PTF_10.2.121 patch. Please open a support case, and request a copy of the patch for your SpectroSERVER's Operating System.
This patch has been rolled into the Spectrum_10.02.01.BMP_10.2.101 patch, and is included in the release of Spectrum 10.2.2.
You may also want to review KB000076838 "CA Spectrum 10.2.x SNMPv3 False Management Agent Lost alarm”
There is a similar defect in Spectrum 9.3.x and Spectrum 9.4.x impacting Spectrum's ability to discover SNMPv3 devices that had been previously discovered and deleted from Spectrum. For that defect, see KB000041286 "Old SNMPv3 Engine ID Records Cause Discoveries To Fail in CA Spectrum" (https://comm.support.ca.com/kb/old-snmpv3-engine-id-records-cause-discoveries-to-fail-in-ca-spectrum/kb000041286)