Not able to fetch all SNMP devices from discovery_server
Article ID: 453912
Updated On:
Products
Issue/Introduction
Customer is creating a probe that uses the get_devices callback in the discovery_server to retrieve a list of SNMP‑supported devices, including their credentials. This works correctly for some devices, but not all SNMP‑supported devices are returned. It appears this may be related to certain origins, but the behavior is inconsistent. For some origins no devices are returned, for some origins only a few devices are returned, and for others all devices are returned. For this purpose, customer is using the get_devices callback with a filter on origin and SNMP support.
Using the get_snmp_devices callback produces essentially the same results.
To investigate why this happens, customer checked the database and noticed two things:
- The table CM_SNMP_SYSTEM is empty.
- The devices that are not returned by the callback have an empty snmp_profile field in the CM_COMPUTER_SYSTEM table.
- Some of the devices without a snmp_profile appear to have two entries in the database, but this is not the case for all of them.
When we run the discovery process, everything appears normal. There are no relevant errors in the discovery_server log, and the SNMP profiles being used seem to be correct. In addition, the SNMP Collector probe shows the correct SNMP credentials and successfully retrieves SNMP data for the devices that are not returned by the discovery_server callback.
From the logs that it seems that the SNMP v3 query for one device fails, but that the SNMP v2c query for another device works.
Note that both the devices respond correctly to SNMP v3 queries from the snmpcollector and snmpget probes with the "same" authentication profile.
This problem seems to be connected to some origins as we have at least one origin were all devices behave correctly for SNMP v3 queries.
Only difference we can see is that in the origin that works SNMP v3 uses privacy (authPriv), but this is not the case for origin used in these tests (authNoPriv). Don't know if this can have any impact.
Also, the logs show the following warning repeatedly.
WARNING: Cannot convert password to key because authentication protocol '1.3.6.1.6.3.10.1.1.2' not found in authProtocols={1.3.6.1.6.3.10.1.1.7=org.snmp4j.security.AuthHMAC384SHA512@762#####, 1.3.6.1.6.3.10.1.1.6=org.snmp4j.security.AuthHMAC256SHA384@33c#####, 1.3.6.1.6.3.10.1.1.5=org.snmp4j.security.AuthHMAC192SHA256@194#####, 1.3.6.1.6.3.10.1.1.4=org.snmp4j.security.AuthHMAC128SHA224@11841386, 1.3.6.1.6.3.10.1.1.3=org.snmp4j.security.AuthSHA@###abcde}
I tried to run the get_devices callback in both our lab, but I received command status: invalid argument. Similar behavior found in discovery_server callbacks | DX Unified Infrastructure Management
Advised the customer to use UIM API as instructed. Below is his response:
This seems to be a side step from the original problem. I believe that we cannot use the REST API as it does not give us all the data we need, but I will have a look into it.
The problem that some devices does not appear as SNMP devices although they supports SNMP, but can be handled as SNMP devices from the snmpcollector/snmpget probes still exist. And as stated before it most likely connected to the SNMP v3 profile we use. We therefore need some advice on how to proceed with the investigation why this happens.
=============
Environment Details:
UIM 23.4.6
snmpcollector-6.031.zip --> provided in 37193 // 36904757 // DE670260 (set_component_user_defined_property_1 callback fails in snmpcollector)
Environment
- DX UIM 23.4 CU6
Resolution
- Hotfix: discovery agent 23.4.6.1 (attached)
Attachments
Feedback
