Troubleshoot SNMP

Symptoms

SNMP problems surface as missing or incomplete device detail: no interface list, no system name, stale firmware version, or a device that never leaves the pending-classification state. AssurIQ reports the exact cause as AIQ-SNMP-001 (timeout) or AIQ-SNMP-002 (authentication failure) against the device.

Timeouts

AIQ-SNMP-001 means the collector sent SNMP requests and received no response before the timeout elapsed.

1. Confirm SNMP is enabled on the device and bound to the management VLAN the collector can reach.
2. Confirm UDP 161 is open from the collector's IP through any device ACL or upstream firewall.
3. Test reachability from the collector host directly, for example with a local snmpwalk against the target IP.
4. For sites connected over high-latency WAN or satellite links, increase the SNMP timeout and retry count in the credential profile's advanced settings rather than assuming the device is unreachable.

Authentication

AIQ-SNMP-002 means the device responded but rejected the credentials presented.

• For SNMPv2c, confirm the community string in the credential profile matches the device exactly, including case.
• For SNMPv3, confirm the username, authentication protocol and privacy protocol all match the device configuration. A mismatch on auth (MD5 vs SHA) or privacy (DES vs AES, or key length) causes a silent authentication failure on most vendors.
• Confirm the account has not been locked out or disabled on the device after a password policy change.

Partial MIB support

Some devices, particularly older switches, consumer-grade access points, and some UPS or PDU firmware, implement only a subset of standard MIBs. This produces a device record with basic identity but missing interface counters, PoE data, or vendor-specific detail.

This is expected behavior, not a fault. AssurIQ records what the device exposes and marks the remaining fields as not collected rather than failing the whole poll. If a specific MIB is required, confirm the vendor's firmware release notes for SNMP support before assuming a configuration error.

Engine ID changes

SNMPv3 authentication is bound to the device's SNMP engine ID. Replacing a device, resetting it to factory defaults, or performing certain firmware upgrades regenerates the engine ID, which invalidates previously cached SNMPv3 session state for that device.

If a device was working and suddenly reports AIQ-SNMP-002 immediately after a hardware swap or factory reset, trigger a fresh discovery cycle so the collector re-negotiates the engine ID rather than waiting for the next scheduled poll.

High-latency sites

Satellite links, cellular failover WAN and some international MPLS circuits can exceed default SNMP timeouts even when the device and credentials are correct. If a whole site shows intermittent SNMP gaps rather than a single device, raise the timeout and retry values for that site's credential profile before troubleshooting individual devices.

Reference

• AIQ-SNMP-001SNMP timeout
  The device did not answer SNMP requests within the timeout.
• AIQ-SNMP-002SNMP authentication failed
  The credential profile was rejected by the device (bad community string or SNMPv3 auth/priv mismatch).

• Configure SNMP Discovery
  Create SNMPv3 credential profiles and enable SNMP on common vendors.
• Network Discovery
  ARP, ICMP, SNMP, LLDP/CDP and DHCP seeding; scopes and schedules.
• Credential Vault
  Storing SNMP, SSH, WinRM and API credentials safely.