Management Lost alerts on Power Supply models.

Document ID : KB000039446
Last Modified Date : 14/02/2018
Show Technical Document Details


We are constantly getting a lot of Management Lost alerts on Power Supply device models, but the device responds by SNMP successfully, which can also be seen in a sniffer trace.   Adjusting the DCM time out, retry or throttle activation and throttle count (even as low as 1) did not influence the behavior in any way. The trace  clearly shows an snmp response from the device, which is ignored again and again by Spectrum.  

In the pcap file we see Spectrum requesting 3 oids.
The device responds with the requested data but Spectrum ignores it and requests again
which is again ignored by Spectrum. sysUpTimeInstance OBJECT IDENTIFIER ::= { sysUpTime 0 } sysName OBJECT-TYPE sysLocation OBJECT-TYPE

When we look at the mibwalk, which completed correctly, we have LEXORDER error on 8 oids, 3 of which correspond to the above.
The mib shows that even though there was an error, they also return the oid value, as below.

#ERROR:LEXORDER: , OctetString , NetMan 100 plus
#ERROR:LEXORDER: , TimeTicks , 00 hrs: 00 min: 00 sec
#ERROR:LEXORDER: , OctetString ,
#ERROR:LEXORDER: , OctetString , ups11kac-c1a
#ERROR:LEXORDER: , OctetString , Kalmar C1A
#ERROR:LEXORDER: , OctetString , 0x006035091346


This behavior is only seen for Aros NetmanPlus UPS Devices.



In the sniffer trace, when Spectrum requests the sysUpTime, the device responds with a value of 17170591211 and Spectrum appears to ignore it and request it again.  However the max allowed value for sysUpTime with SNMP v1 is 4294967296, so the returned value from this device, is way over the allowed value.  As a result of this non compliant SNMP v1 value,  Spectrum rejects the returned value and Sapwalk has a LEXORDER error beside the returned value.



Rebooting the device does not initialize the sysUpTime and looking at the devices internal clock we see other unusual behaviour such as a current date of 2054.  Please discuss any such incedents with the vendor, to get a solution to this device problem.



Delete this SNMP v1 model and rediscover as v2, where larger sysUptimes are accepted.


Additional Information: