SNMP-based services showing Unknown, or an SNMP host that added with no automatic services, almost always comes down to one of a small number of causes. This checklist expands on the "Common problems" section in SNMP Monitoring.
Checklist
- Credentials — confirm the community string (v1/v2c) or username, auth, and privacy settings (v3) configured in iPM exactly match what's set on the device. This is the single most common cause of SNMP failures.
- SNMP enabled on the device — some devices ship with SNMP disabled by default, or only enabled after a specific configuration step.
- Version mismatch — confirm iPM is configured for the same SNMP version (v1, v2c, or v3) the device is actually running. A v3-only device won't respond to a v2c query, and will simply time out rather than returning a clear error.
- Access restrictions — check whether the device has an SNMP access list (ACL) that needs the iPM server's IP explicitly permitted. Many network devices, Cisco gear especially, ship locked down by default beyond the local subnet.
- Network path — confirm UDP 161 (and 162, if using traps) isn't blocked by a firewall between iPM and the device, the same way you'd check for a blocked port with any other protocol.
- Unsupported OID/MIB — if only one specific metric shows Unknown while others on the same device work fine, the device may simply not expose that particular OID. Not every device implements every MIB.
Isolating the problem
If you have separate shell access to a Linux host, running a manual `snmpwalk` against the device with the same credentials iPM is configured with is one of the fastest ways to confirm whether the problem is SNMP configuration on the device, or something specific to how iPM is querying it — if the manual walk also fails, the issue is entirely on the device/network side, not in iPM.
Still stuck after all of this? Confirm basic reachability first — see Device Not Reachable — since an SNMP query naturally fails if the device isn't reachable at all.