When experiencing issues with SNMP in AirWave 8.2.6 or newer, here's a quick troubleshooting guide
1) Test creds
2) Check SNMP version
3) Check timeout and retries
4) Test timeout
5) Big hammer: Restart all services
:: Test Creds ::
Try doing SNMP walks from the AMPCLI to test the credentials in the database. To do this, you'll need to know the device's ID which is gotten from the URL when you view the device's monitor page.
Example URL:
https://airwave.lab.com/ap_monitoring?id=2421
The ID is 2421
In CLI: go to 'Enter Commands' (opt 11)
$ ?sw
sw <ap_id> args [-o fname ] ... - snmp walk protocol v1 - see 'man snmpbulkwalk'
sw2 <ap_id> args [-o fname ] ... - snmp walk protocol v2c - see 'man snmpwalk'
sw3 <ap_id> args [-o fname ] ... - snmp walk protocol v3 - see 'man snmpbulkwalk'
With '-o fname' the output will be saved in the CLI user directory.
$ sw2 2421 sysName
SNMPv2-MIB::sysName.0 = STRING: jamaica-test-aos65
If you get a valid output like above, then the credentials are correct. If you're on older code - it might just be easier to go to the device's management page and updating the creds with the correct creds.
:: Check SNMP version ::
Go to Groups -> select group -> Basics page
Under the specific supported Device type breakout - check that SNMP version used to communicate with your device is set to the right version.
:: Check timeout and retries ::
Go to Device Setup -> Communication
Check values for SNMP timeout and SNMP retries
Some devices require longer timeouts, especially if the tables are larger to gather or if the devices SNMP proto is slower like legacy Motorola controllers which require the max timeout.
:: Test timeout ::
From the AMPCLI again
In CLI: go to 'Enter Commands' (opt 11)
$ ?sw
sw <ap_id> args [-o fname ] ... - snmp walk protocol v1 - see 'man snmpbulkwalk'
sw2 <ap_id> args [-o fname ] ... - snmp walk protocol v2c - see 'man snmpwalk'
sw3 <ap_id> args [-o fname ] ... - snmp walk protocol v3 - see 'man snmpbulkwalk'
With '-o fname' the output will be saved in the CLI user directory.
$ sw2 2421 .1 -Cc
Running .1 is collecting the entire MIB table. You could also isolate to specific tables that are larger like the BSSID table (for Aruba controllers: wlsxWlanAPBssidTable) or client usage tables (for Aruba controllers: nUserName or nUser6Name). If you're seeing the timeout happening frequently even when at max setting, then open a support case for further debugging. Support may have to manually increase the timeout value beyond what the UI allows (but this makes the Device Communication page obsolete as any setting change would revert the timeout back to the max allowed).
:: Big Hammer - Restart of all AMP services ::
If you choose not to try to debug the cause and just want to see if the services are stalled, then you can go to System -> Status, at the bottom of the page is Restart AMP option.
AMPCLI also has a parallel option under the Advanced (8) -> Restart Application (1).