SpectroSERVER asserting the "MANAGEMENT AGENT LOST" alarms at the same time on multiple models managed using SNMP v3
Article ID: 226249
Updated On:
Products
Issue/Introduction
SpectroSERVER asserting the "MANAGEMENT AGENT LOST" alarms at the same time on multiple models managed using SNMP v3.
Unable to model a v3 device but able to sapwalk the same device.
error in ADiscDebug
Jul 25 13:24:08 Unmanaged Trap IH: 10.10.10.10
Jul 25 13:24:08 Unmanaged Trap IH: Just tried this trap IP 10.10.10.10 1072 seconds ago. Will not try again.
Jul 25 13:24:23 IP Discovery 10.10.10.10: mtype identification failed at community name #v3/P:<STRING>:AES^<STRING>//<v3user> and SNMP port 161 with error: 1
Jul 25 13:24:23 Reading IP address table:
Environment
Release : 22.2.x
Component : Spectrum Core / SpectroSERVER
Cause
Spectrum caches the SNMP v3 profile data used to manage devices with SNMP v3.
Sometimes, this cached 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.
It also causes the wrong strings to be sent during discovery process.
Resolution
The solution is to flush the SNMP v3 cache by doing the following:
1. Log into the SpectroSERVER system as the user that owns the Spectrum installation
2. If on Windows, start a bash shell by running "bash -login"
3. cd to the $SPECROOT/vnmsh directory and enter the following command to start a CLI session:
./connect
4. Enter the following command where <MH> is the model handle of the VNM model for this landscape:
./update action=0x10333 mh=<MH>
E.G.
./update action=0x10333 mh=0x1000000
The SNMP v3 cache will be flushed and rebuilt as Spectrum communicates with the devices being modeled using SNMP v3.
Feedback
