snmpcollector fails to monitor "special use" SNMP devices
Article ID: 4466
Updated On:
Products
Issue/Introduction
Cannot add a profile for a "special use server" (one that does not return values for the SNMPv2-MIB::system OIDS SysUpTime or sysOid). Attempting to discover the device from snmpcollector using snmpv3 SHA/AES128 credentials., the "discovery" fails with the Failure pop-up message:
SNMP credentials are not valid for hostname <IP address of device>
An snmpwalk of this device for the metrics to be monitored using the same set of SNMPv3 SHA/AES credentials works; however, an snmpwalk of the system MIBs (using the same set of SNMPv3 credentials) fails with the following:
SNMPv2-MIB::system = No Such Object available on this agent at this OID
Environment
snmpcollector through release 3.20 and above
Cause
The snmpcollector probe version 3.20 and earlier require the device to provide a value of either the sysUpTime or sysOID SNMPv2-MIB::system OIDs in order for the probe to be able to discover the device. If neither of these values are available, the probe cannot be used to monitor these devices. At least one of the following snmpwalk commands must succeed in order to be able to monitor the device (examples shown using SNMPv3):
snmpwalk -v3 -l authPriv -u <username> -a SHA -A xxx -x AES -X xxx <device IP address> systemUptime
HOST-RESOURCES-MIB::hrSystemUptime = No Such Object available on this agent at this OID
snmpwalk -v3 -l authPriv -u <username> -a SHA -A xxx -x AES -X xxx <device IP address> sysObjectID
SNMPv2-MIB::sysObjectID = No Such Object available on this agent at this OID
The error message displayed by the probe is erroneous. There is nothing wrong with the credentials used to discover the device. The problem is that the required set of OIDs are not available from the device the probe is attempting to discover. The following will appear in the snmpcollector.log file:
Aug 02 10:32:05:643 [attach_socket, snmpcollector] Running callback to create snmp device
Aug 02 10:32:05:643 [attach_socket, snmpcollector] propertyValues = {Port=161, Retries=3, Timeout=2000, description=VDE, hostnameOrIP=<device IP address>, snmpCredentialsMux={snmpv3={username=<username>, SNMPv3TypeMux={authPriv={authProtocolDefinition=SHA, authenticationKey=<auth key>, privacyProtocol=AES128, privateKey=<private key>}}}}, userDefinedProperty1=VDE}
Aug 02 10:32:05:879 [attach_socket, snmpcollector] Communicating with target <device IP address>/161: SNMP version 3 Timeout 2000 Num Retries 3
Aug 02 10:32:15:355 [attach_socket, snmpcollector] Running get CTD callback
Aug 02 10:32:15:355 [attach_socket, snmpcollector] PDS is encrypted
Aug 02 10:32:15:355 [attach_socket, snmpcollector] PDS has been decrypted
Aug 02 10:32:15:355 [attach_socket, snmpcollector] PDS contained the key ctd_version
Aug 02 10:32:15:355 [attach_socket, snmpcollector] PDS contained the key ctd_object_id
Aug 02 10:32:15:355 [attach_socket, snmpcollector] PDS contained the key include_scheme
Aug 02 10:32:15:355 [attach_socket, snmpcollector] PDS contained the key probe_address
Aug 02 10:32:15:355 [attach_socket, snmpcollector] PDS contained the key depth
Aug 02 10:32:15:355 [attach_socket, snmpcollector] getCtdConfigurationCallback: extractedProbeAddress = /<UIM domain name>/<UIM hub name>/<UIM robotname>/snmpcollector
Aug 02 10:32:15:355 [attach_socket, snmpcollector] getCtdConfigurationCallback: extractedObjectId =
Aug 02 10:32:15:355 [attach_socket, snmpcollector] getCtdConfigurationCallback: extractedDepth = null
Aug 02 10:32:15:355 [attach_socket, snmpcollector] getCtdConfigurationCallback: additionalArguments = {}
Resolution
snmpcollector version 3.21 and above contains a fix for the issue in which discovery failed for devices that do not report SysUpTime
NOTE: If the monitored device does not report SysUpTime, the probe cannot monitor for availability or reachability metrics since both of of these rely on sysUptime. These devices can be discovered and monitored for other available metrics for the device once it is discovered.
Feedback
