Wireless Access

Hi @all,

 

I'm trying to solve what I thought should be one of _the_ most common questions any SE running an infrastructure should have: are there any devices down, and if so which ones?

Any corresponding alert should, of course, be coming from the monitoring-system of choice.

 

Approach #1: SNMP

After having gone through the ArubaOS_6.1MG.pdf I found that "globalAPState" should at least be able to provide the number of down APs per controller - theoretically.

But when  querying OID .1.3.6.1.4.1.14823.2.2.1.1.3.4.1.6 all controllers tested so far return a "No data available."-answer instead.

When walking the MIB tree I found information on down APs (below "Access point %1d is down"), but this information seems to be coming from RFP or ARM as opposed to the AP database. It contains a lot of redundant information, e.g. even APs no longer visible in the AP db, as well as multiple entries with the same MAC addresses.

 

Is there any trivial way to get all provisioned APs in state "down", i.e. at least a list with the ap-names, IP addresses etc., via SNMP?

 

How do you determine down APs with your monitoring-systems (other than AWMS)?

 

 

Best regards,

Mike

 

 

P.S.: Approach #2 wouuld be to script this via SSH, but I don't want to go down that road yet... ;)

 

Knowledge Base Answer ID 593 and ID 1445 contain some good information. Here, we walk, and receive a list of all APs connected to the queried controller, and the AP type for each: snmpwalk -On -v 2c -c public 192.168.17.253 .1.3.6.1.4.1.14823.2.2.1.1.3.3.1.7 .1.3.6.1.4.1.14823.2.2.1.1.3.3.1.7.0.11.134.236.227.177 = INTEGER: ap(1) .1.3.6.1.4.1.14823.2.2.1.1.3.3.1.7.0.26.30.246.99.224 = INTEGER: am(2) .1.3.6.1.4.1.14823.2.2.1.1.3.3.1.7.0.26.30.246.99.232 = INTEGER: am(2) Note: This MIB is indexed by apBSSID, so it's not really representative of the physical AP itself, and to query any specific AP, one needs to know the BSSID, and convert this to decimal to form the query. One can poll this MIB, and potentially threshold on a decreasing value to know if APs are going down: wlsxWlanTotalNumAccessPoints.1.3.6.1.4.1.14823.2.2.1.5.2.1.1 - returns the number of active APs on the queried controller. The wlsxSwitchGlobalAPEntry MIB was deprecated some time ago. The recommended MIB is: wlsxWlanAPTable .1.3.6.1.4.1.14823.2.2.1.5 Which contains, amongst others: wlanAPStatus .1.3.6.1.4.1.14823.2.2.1.5.2.1.4.1.19 Which is indexed by wlanAPMacAddress A walk of this table starts out like this: snmpwalk -On -v 2c -c public 192.168.17.253 wlsxWlanAPTable .1.3.6.1.4.1.14823.2.2.1.5.2.1.4.1.2.0.11.134.198.206.58 = IpAddress: 192.168.17.214 .1.3.6.1.4.1.14823.2.2.1.5.2.1.4.1.2.0.11.134.199.57.82 = IpAddress: 192.168.17.134 .1.3.6.1.4.1.14823.2.2.1.5.2.1.4.1.2.0.11.134.201.183.210 = IpAddress: 192.168.17.207 etc... Now performing a GET on the status MIB for one specific AP: (granted - that I know the AP MAC and have converted to decimal) snmpwalk -On -v 2c -c public 192.168.17.253 .1.3.6.1.4.1.14823.2.2.1.5.2.1.4.1.19.0.11.134.198.206.58 .1.3.6.1.4.1.14823.2.2.1.5.2.1.4.1.19.0.11.134.198.206.58 = INTEGER: up(1) We currently have Enhancement request RFE 2170, which outlines the need for a non indexed MIB which indicates the AP status.

@sadams: Many thanks! You are, of course, absolutely right.

 

Having to automate this for let's say a few hundred (or even thousand) APs (having been deployed by people other than oneself) might prove to be a non-trivial task.

You'd first have to extract a list of all known APs, their MAC addresses and OIDs, then parse and convert all of those MAC addresses to decimal, then construct all relevant OIDs, then retrieve the corresponding stati, then filter out all being in status down ("0" if I'm not mistaken) - and then find out the ones being shown as "down" because they really are and the ones having been left over from whatever else might have happened before, having left behind it's traces in the innards of the controller and also populating this table.

 

I know that this, of all moments, would be the perfect moment to throw AWMS into the ring ;)

However, this might not always be an option.

 

I'll see if I and how can second that RFE 2170. :)

 

 

Many thanks once again for lending a helping hand!