Following are some reasons that snmpcollector could connect to a device but not collect metrics.
1. "getnext" command does not work as expected on the target device. By default, snmpcollector asks for 20 metrics at a time with “getnext”. Some devices, like Cisco 3850s cannot do this.
To work around this limitation, in the snmpcollector Raw Config, setup folder, add a key called MAX_BATCH and set the value to something lower than 20. 3 works with many devices, but customers can test with different numbers by starting at 1 and working up until the issue re-occurs. The higher this number is, the more efficiently snmpcollector can collect metrics. Support does not recommend going over 20.
2. This could also be a vendor certification problem. In other words, snmpcollector does not have the correct MIBs to talk to this device.
To resolve this, Ensure the device_certification_deployer, (DCD), has been deployed to the snmpcollector hub and that the probe callback "load_device_cert_files" has been run. To be sure the correct MIB is deployed, check the list returned by the probe callback, "list_vender_cert". If the appropriate MIBs do not appear, open a case with the UIM Support Team.
3. The target device is too busy to answer. The management interface on most snmp devices is designed to give management traffic very low priority. Having said this, it is uncommon for metrics to be missed for more than one or two polling cycles.
4. This behavior has been observed when snmpcollector was unable to pull metrics from certain devices when it had some local memory issues. The snmpcollector VM was configured to use dynamically assigned memory. When the VM was given dedicated memory, this problem was resolved.