Troubleshooting SNMP from the Auvik Collector

Access the diagnostic shell on the Auvik Collector

• Windows:
  • Launch Command Prompt as Administrator.
  • Navigate to the install directory, e.g., cd C:\auvik.

  • Run:

    AuvikAgentService -shell

• Linux/Docker:
  • With Docker Compose:
    • From the host machine, open a terminal window
    • Change directories to the location of the Docker compose configuration file

    • Run the following command to start the agent shell, replacing <SERVICE_NAME> with the service name defined within the Docker compose file:

      docker compose exec -it <SERVICE_NAME> /var/auvik/bin/agent -x

      Note: The <SERVICE_NAME> will be dependent on the deployment configuration. The service name will be based on the entry within the Docker compose file, specifically under the services section.

  • Standalone Docker:If your Docker image was not deployed using Docker compose, or you do not have access to the Docker compose configuration, then the following Docker commands can be used to start an agent shell process.From the host machine, open a terminal window

    • Run the following Docker command:

      docker exec -it <container_name_or_id> /var/auvik/bin/agent -x

      Note: The <container name/id> will be dependent on the deployment. If using Docker compose for the deployment, this will be the container_name used in the docker-compose.yaml file.
      
      If no name was specified during the configuration, a Docker will set a default name. This can be found using docker ps command to list all running containers. Once the correct container has been identified, the container id OR the container name can be used in the above command.  Failure to keep the Docker image up to date can cause the collector to fail with these updates, causing instability and disconnects.

• Virtual Collector:
  • Open the collector’s VM console via your hypervisor.
  • At the menu, select Option 6, then confirm with Y—this drops you into the bash shell.
  • Run this command

    • For Ubuntu 22.04:

      sudo /usr/share/agent/bin/agent_shell

       

    • For Ubuntu 24.04:

      sudo /usr/share/auvik/agent/bin/agent_shell

Debug Commands to Understand SNMP Issues

The most common answers have to do with devices not being configured correctly, or incorrect credentials being used. The diagnostic shell has a few debug commands that can help to understand SNMP issues:

snmpcred sets the credentials that will be used by the other commands.

For SNMP v1/2c:

snmpcred community private

snmpcred version v1 community private

For SNMP v3, with the auth protocol of MD5:

snmpcred user V3User auth md5 
md5password priv des des56password

snmpcred user V3User auth md5 
md5password priv desede desedepassword

snmpcred user V3User auth md5 
md5password priv aes192 aes192password

snmpcred user V3User auth md5 
md5password priv aes256 aes265password

For SNMP v3, with the auth protocol of SHA:

snmpcred user V3User auth sha 
shapassword priv des despassword

snmpcred user V3User auth sha 
shapassword priv desede desedepassword

snmpcred user V3User auth sha 
shapassword priv aes192 aes192password

snmpcred user V3User auth sha 
shapassword priv aes256 aes265password

Setting Auvik shell credentials for Cisco devices running SNMPv3 privacy above AES-128: Cisco uses what they call 3-DES key extension as part of the protocol; therefore to account for this, you'll need to add a "w3des" suffix to the privacy parameter e.g - when using AES-256, you would specify: priv aes256w3des aespassword

If snmpcred isn't invoked at all, or is invoked without any arguments, the default configuration is used: snmp v2c community authentication with community string "public".

snmpget attempts to fetch one or more OIDs from the host at a specified IP address using an SNMP GET request. If only an IP address is specified it fetches the OID sysDescr.0. To fetch other OIDs, any number of numeric OID identifiers can be specified following the IP address. Note that it doesn’t support symbolic OID names like the net-snmp tools do.

snmpgetnext is like snmpget except it uses an SNMP GETNEXT request.

snmpgetbulk is like snmpget except it uses an SNMP GETBULK request.

SNMP has no "authentication failed" response, so a failed authentication is generally indistinguishable from "host down or not present".

For example:

auvik> snmpcred user V3User auth md5 md5password priv des des56password
user {
security_name: "V3User"
auth_protocol: SNMP_AUTH_MD5
auth_passphrase: "md5password"
privacy_protocol: SNMP_PRIVACY_DES
privacy_passphrase: "des56password"
}

auvik> snmpget 10.0.40.1
[1.3.6.1.2.1.1.1.0]: snmpString
(Cisco IOS Software, 2801 Software (C2801-ADVENTERPRISEK9-M), 
Version 12.4(17), RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2007 by Cisco Systems, Inc.
Compiled Fri 07-Sep-07 17:15 by prod_rel_team)

auvik> snmpget 10.0.40.1 1.3.6.1.2.1.1.5.0
[1.3.6.1.2.1.1.5.0]: snmpString
(CISCO_2801.auvik.local)

auvik> snmpget 10.0.40.2
snmp request returned no result

auvik>

snmpwalk attempts to retrieve all OIDS from a specified host that have a common prefix. If only an IP address is specific, snmpwalk will fetch all OIDs starting with 1.3.6.1.2.1.1. To fetch more or different OIDs, a different prefix can be specified as an additional parameter.

For example:

auvik> snmpwalk 10.0.40.3 1.3.6.1.2.1.1

[1.3.6.1.2.1.1.1.0]: snmpString(SonicWALL NSA 2400 (SonicOS Enhanced 5.8.1.14-68o))
[1.3.6.1.2.1.1.2.0]: oid([1.3.6.1.4.1.8741.1])
[1.3.6.1.2.1.1.3.0]: long(0x348e7c13e90)
[1.3.6.1.2.1.1.4.0]: snmpString(Alex Hoff)
[1.3.6.1.2.1.1.5.0]: snmpString(Auvik's SonicWall 2400)
[1.3.6.1.2.1.1.6.0]: snmpString()
[1.3.6.1.2.1.1.7.0]: int(0x4f)

Troubleshoot widespread SNMP failures

Use this section when SNMP polling is failing across multiple devices or sites and restarting the affected Collectors has not resolved the issue.

Identify the scope

Before testing, note whether the issue affects:

• All devices or only specific sites
• SNMPv2c, SNMPv3, or both
• Specific device vendors or models
• One Collector or multiple Collectors

Also check the Auvik status page for your region for any active service incident.

Test from each Collector’s network path

Run the tests from each Collector, if shell access is available. If you cannot access a Collector shell, use a host in the same VLAN or subnet as the devices. The test host must be permitted by the device’s SNMP access controls.

SNMPv2c

Test a system description:

snmpget -v2c -c <community> <device_ip> 1.3.6.1.2.1.1.1.0

Walk the basic system OIDs:

snmpwalk -v2c -c <community> <device_ip> 1.3.6.1.2.1.1

SNMPv3

For authentication and privacy:

snmpget -v3 -l authPriv -u <user> -a SHA -A <auth_password> -x AES -X <privacy_password> <device_ip> 1.3.6.1.2.1.1.1.0

For authentication without privacy:

snmpget -v3 -l authNoPriv -u <user> -a SHA -A <auth_password> <device_ip> 1.3.6.1.2.1.1.1.0

If a single request fails, try a basic system walk:

snmpwalk -v3 -l authPriv -u <user> -a SHA -A <auth_password> -x AES -X <privacy_password> <device_ip> 1.3.6.1.2.1.1

Interpret the results

• Timeout or no response: Check routing, firewalls, ACLs, whether SNMP is enabled, and whether the device is overloaded.
• Authorization error: Check the SNMP community string or SNMPv3 username, authentication, privacy settings, security level, and permitted SNMP view.
• Partial results: Check whether the SNMP view excludes required OIDs or whether the device is rate-limiting SNMP responses.
• Works from one Collector but not another: Compare the source IP, routing path, NAT, and device ACLs for each Collector.
• Fails from both Collectors: Investigate the device configuration, shared network controls, credentials, or a widespread configuration change.

If SNMP tests succeed from both Collectors

In Auvik, verify that:

• The SNMP credential matches the values that succeeded in testing.
• The credential is assigned to the affected sites or devices.
• An older or invalid credential is not being selected instead.
• The detected SNMP version matches the device configuration.
• The device is assigned to a Collector that can reach it.

After making corrections, run a discovery or rescan and allow time for the next polling cycle.

Check for shared changes

For widespread failures, review recent changes to:

• Shared SNMP credentials or credential templates
• Device ACLs and firewall rules
• Routing, VPN, or NAT configuration
• Device firmware
• SNMP views, users, groups, or engine IDs

Information to collect for Support

If the issue continues, provide:

• Affected sites and representative devices from different subnets or vendors
• Collector names and source IP addresses
• The exact snmpget or snmpwalk commands used
• Sanitized command output from each Collector or test host
• Test timestamps and timezone
• Screenshots of device SNMP settings with secrets removed
• Recent network, credential, firmware, or ACL changes

Verify SNMP outside of Auvik

Testing SNMP with an external tool can help determine whether the issue is with the device, network path, credentials, or Auvik polling.

Run the test from a system that has network access to the device. Ideally, test from the collector host or from the same network path.

SNMPv2c test

snmpwalk -v2c -c <COMMUNITY> <DEVICE_IP> 1.3.6.1.2.1.1

SNMPv3 test

snmpwalk -v3 -u <USER> -l authPriv -a SHA -A <AUTH_PASSPHRASE> -x AES -X <PRIV_PASSPHRASE> <DEVICE_IP> 1.3.6.1.2.1.1

Replace the placeholders with the device’s actual SNMP configuration.

What to look for

A successful test should return consistent and timely responses, including values such as:

• sysDescr
• sysObjectID
• sysName
• Interface information, when included in the queried OID

Also check for:

• Timeouts or intermittent failures.
• Unexpected or changing identity values.
• Incomplete interface tables.
• Significant response delays.

If the test fails

Verify:

• The device’s SNMP agent is enabled.
• The tested source IP is permitted by the device’s SNMP access list or ACL.
• The SNMPv2c community string or SNMPv3 credentials are correct.
• The configured MIB view includes the queried OIDs.
• Firewalls and network ACLs allow SNMP traffic.
• Device latency, packet loss, CPU usage, and memory usage are within normal limits.

When to contact Support

Contact Auvik Support if external SNMP tests succeed but polling in Auvik remains incorrect or inconsistent.

Include:

• The exact commands used, with credentials removed.
• Sanitized command output.
• A summary of the device’s SNMP configuration.
• Device and collector IP addresses.
• Date, time, and timezone of the tests.
• Any related Auvik polling errors.

Testing may require command-line access and access to device or network configuration. Changes to SNMP settings, ACLs, firewalls, or MIB views may require a device or network administrator.

Troubleshoot intermittent SNMP data

Use this workflow when some devices or metrics report consistently while others have gaps, or when SNMP tests pass intermittently.

Identify the pattern

Determine whether the issue is limited to:

• Specific device models or firmware versions.
• Particular sites or network paths.
• Large SNMP tables such as ARP, bridge/MAC, or routing tables.
• Periods when device CPU or memory usage is high.
• Specific SNMPv3 credentials or security settings.

Test stable and large SNMP responses

From the collector or a system on the same subnet, test a stable system OID and, if appropriate, a larger table.

SNMPv2c system OID:

snmpwalk -v2c -c <COMMUNITY> -t 3 -r 2 <DEVICE_IP> 1.3.6.1.2.1.1

SNMPv2c bridge/MAC table:

snmpbulkwalk -v2c -c <COMMUNITY> -Cr10 <DEVICE_IP> 1.3.6.1.2.1.17.4.3

SNMPv3 system OID:

snmpwalk -v3 -l authPriv -u <USER> -a SHA -A <AUTH_PASSPHRASE> -x AES -X <PRIV_PASSPHRASE> <DEVICE_IP> 1.3.6.1.2.1.1

Look for timeouts that occur only with large tables or during specific time periods.

Do not include SNMP communities, passwords, or passphrases in Support requests or shared command output.

Check the device and SNMP configuration

Verify that:

• Device CPU and memory are stable during polling.
• SNMP views include the OIDs required for monitoring.
• SNMP rate limits are not blocking or delaying responses.
• ACLs and firewalls consistently allow UDP 161 from the collector.
• The SNMPv3 engine ID has not changed.
• SNMPv3 authentication, privacy, and security-level settings match in Auvik and on the device.

Device-side SNMP queue, rate-limit, view, ACL, and engine-ID changes may require assistance from a network or device administrator.

Check the network path

Test for:

• Latency and packet loss between the collector and device.
• Jitter or congestion during polling windows.
• MTU or fragmentation problems affecting larger SNMP responses.
• Asymmetric routing or intermediate firewall behavior.

If large responses fail, reduce the SNMP bulk size or use non-bulk GETNEXT polling where the device or monitoring platform supports those options.

Tuning and remediation

Where supported:

• Increase SNMP timeouts or retries for affected devices.
• Reduce the bulk size for devices that cannot process large responses reliably.
• Stagger polling for large environments.
• Exclude unstable or extremely large tables if they are not required for monitoring.
• Address device firmware issues related to SNMP polling.

Using SNMPv2c instead of SNMPv3 may be useful for controlled testing, but SNMPv3 should remain the preferred production configuration when supported.

Verify the results

After making changes:

1. Monitor at least one complete polling cycle.
2. Compare Auvik data with the device’s SNMP-agent logs.
3. Review collector logs for timeouts, access denials, or incomplete responses.
4. Confirm that previously missing metrics are updating consistently.

If the issue persists, provide Support with the affected device models and firmware versions, timestamps, sanitized SNMP test results, and relevant collector or device log entries.

No end-user steps were removed. Device configuration, firmware, ACL, firewall, rate-limit, and SNMP-agent changes may require a network or device administrator.

Evidence to collect

Document the affected devices and timestamps, then collect:

• Collector and device IP addresses.
• SNMP error messages or timeout details.
• Network, firewall, and ACL logs.
• SNMP walk samples from affected devices.
• Device CPU and memory data during the issue.
• MAC-table, LLDP, or CDP output where topology data is incomplete.

Provide this information to Support if the issue continues.