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

    sudo /usr/share/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)