When managing SNMPv3 devices in Spectrum, you may experience a false Management Agent Lost alarm. Using the "Reconfiguration -> Reset SNMPv3 Authentication" does not appear to work or doesn't resolve the problem. When you run a sniffer trace you see that either a different engineid is being sent to Spectrum or Spectrum is "looping" in the communication (the SS sends a blank request for the v3 info, the agent sends the report packet back. Instead of Spectrum then using that data to send the next request, Spectrum sends a blank request again for the v3 info. This cycle repeats).
If you stop and restart the SpectroSERVER the issue is cleared. This is because the entire SNMPv3 cache is cleared and rebuilt when the SS is restarted.
The problem is due to running action code 0x10330 debugging the issue:
There are two tables in the Spectrum cache that store the IP/engineid. When using action code 0x10330 to clear the v3 cache, it only removes the engine id from one table.
A new action code of 0x10333 has been introduced that will properly remove all engineid entries from the cache.
This is available in BMP2 for 10.2.2 and BMP1 for 10.2.3. This is also available in 10.3 and above.
If there is an SNMPv3 issue you need to troubleshoot, you should first use the "Reset SNMPv3 Authentication". If that does not work, then you can use the update action code of 0x10333 command in CLI:
./update action=0x10333 mh=<mh_of_VNM>
This will clear the SNMPv3 cache. At any time you can view the cache using action code 0x10331:
./update action=0x10331 mh=<mh_of_VNM>
If you are unable to upgrade Spectrum, then to resolve this issue you need to stop and restart the SpectroSERVER which flushes and rebuilds the SNMPv3 cache.
Please make sure you are on an updated version of Spectrum and have installed the necessary patches as well for the SNMPv3 authentication reset failure: