Monitoring of Wireless Access Points through Controller

We are a Cisco shop and previously had been aware you could utilize the controller as a monitored node, but then be notified of access points going up/down when they register or drop off the controller. While in NPM, I can see the controller, and the thin access points connected to it, but I cannot monitor them (at least not to alert upon) for up/down.

Is there a simple way to configure this, without having to add each AP for monitoring?

Find more posts tagged with

wireless_ap

status

Accepted answers

stuartd

What conditions do you have on the trigger? This is what ours looks like:

If you prefer, then the SWQL looks like this:

SELECT E0.[Uri], E0.[DisplayName]
FROM Orion.Packages.Wireless.AccessPoints AS E0 
WHERE ( ( ( E0.[Node].[CustomProperties].[Node_In_BAU] = 'True' ) ) AND ( ( E0.[Status] = '2' ) ) )

And yes, we don't alert until said AP has been down for >1hr as users are so fond of moving them or power cycling them to fix perceived faults.

All comments

jm_sysadmin

My network team is using alerts from Cisco software to do this so I can't confirm if this works. In Orion I would use some combination of the status below, did you try disassociated or disappeared?

Monty30381

Not yet, let me try that, but am unsure it fires an appropriate alert... but let me see.

We also use Prime but it is too noisy to be of use for looking for Access Point failures... my NOC can't decipher it.

Monty30381

Executed an alert like this, had no effect. I did both the disappeared and the disassociated, then took some AP's offline.

It feels like there should be some more settings... like making an alert for a 'controller' then AP's that disappear from it... not like this general of an alert...

So still searching for an answer... thanks, but it didn't quite do it.

superfly

Solarwinds includes an out of the box alert for when a thin AP goes down. I've used it in the past for Cisco AP's. Works great.

stuartd

Agreed - this works for us and an edited version also works to include Aruba and other AP manufacturers that manage their APs via a WLC.

Monty30381

Yes, sounds great. Doesn't work.

I've turned it on with notifications and when we take an AP down, we still receive no alerting. Will test again, perhaps they have repaired it with the newer version.

stuartd

What conditions do you have on the trigger? This is what ours looks like:

If you prefer, then the SWQL looks like this:

SELECT E0.[Uri], E0.[DisplayName]
FROM Orion.Packages.Wireless.AccessPoints AS E0 
WHERE ( ( ( E0.[Node].[CustomProperties].[Node_In_BAU] = 'True' ) ) AND ( ( E0.[Status] = '2' ) ) )

And yes, we don't alert until said AP has been down for >1hr as users are so fond of moving them or power cycling them to fix perceived faults.

Monty30381

So, taking the out-of-the box alert exactly as is comes...

Thus, Thin Access Point, and status of Down.

We're currently waiting to see if it ever alerts... has been down about 10 minutes so far.

ioan_bucsa

Alerting on Cisco thin APs can be a bit of a headache even though it seems quite trivial at a glance.

Part of it is because of how Cisco designed the system; basically, when an AP is disassociated from a controller it just removes it from its list of APs (in theory there is a 'Disassociating' operational status for APs, but to be honest I have not seen that showing up).

Then there's the fact that there is no clear correlation between AP operational statuses per Cisco (AIRESPACE-WIRELESS-MIB defines the following: Associated, Disassociating and Downloading) and SolarWinds AP statuses (Up, Down, Unknown, Disassociated, Disappeared). I have received a few possible explanations from support, but not quite satisfactory. Based on our observations the only Up, Down and Unknown actually apply to Cisco APs (the other 2 were probably intended for other vendors).

The three statuses explained (again, based on our findings):

Up - corresponds to Associated; AP is associated to controller and reachable

Unknown - AP is no longer associated to the controller as of latest poll (it was associated at the previous poll) and will be completely removed from SolarWinds by the next polling cycle if status persists

Down - AP is associated but not reachable (or is stuck downloading the image or some other issue)

Based on the findings above it's quite tricky to define a reliable AP alert. Normally you would set the trigger condition to check for APs that are 'Unknown' or 'Down' while the controller is 'Up' every X minutes and remain in that state for at least Y minutes. The problem is that X+Y must be lower than your polling cycle because 'Unknown' APs are removed each polling cycle and you are going to miss a lot of alerts. If you set X+Y too low then you risk to be flooded by AP alerts (especially if you have thousands like we do), but if you set it too high (closer to the polling cycle) you risk missing quite a few alerts.

In conclusion, if you don't have that many APs (the number is quite subjective) and you are fine with getting alerts for minor events (less downtime) then you would set the trigger condition to AP status is ('Unknown' OR 'Down') AND controller is 'Up' and must remain in that state for at least Y minutes. Alert frequency is every X minutes. Set X+Y to a lower value (for example, if you polling cycle is 5 minutes then you could set X = 1 and Y=2) so that you do not miss alerts and the alert volume is not too high.

Hope this makes sense.