Your Thoughts on Thin AP Alerting?

We're looking into how thin AP monitoring works today and would like your input. How does thin AP alerting and other aspects of monitoring thin APs work for you? Are there areas where you feel we're doing good or bad? What would you add or remove about our current functionality.

I'm interested in your thoughts!

Find more posts tagged with

Accepted answers

All comments

sja

RichardLetts

I quite sure you have a take on that...

RichardLetts

Note: I've moved jobs so I have not looked at it on the platform here (cisco).

Aruba Thin AP alert support is poor.

1. There is no way to mark an AP as out of service -- sometimes we have to take them down for construction temporarlyand it would be good to be able to flag them as out of service.

2. There is no way to manually remove a single AP, sure you can remove disappeared AP, but that is a very blunt tool

but to the actual question on alerting:

3. in the Aruba environment the thin AP is associated with a wireless controller, However that paradigm is fundamentally broken (at AOS6) and even more broken (at AOS8)

this is because a single AP can have either a redundant (active/passive) connection to two controllers, or dual-active connections, or a number of connections to a cluster depending how you've configured the AP group and how the controllers are configured, and the version of the OS.

this means you have normally TWO thin AP in the database for one phsicalAP -- the two thin ap will have the same name e.g. ADS.004.AP01, IP address, and MAC address but will have separate NODEID (for the controller)

I needed to have alerts which represent:

AP (name) is down on All controllers (one alert) -- it's really is dead

AP (name) is down on one controller (Controller Name) -- it may be disconnected

right now I can only have the latter alert (out of the box) which doesn't represent the operational state of the AP.

there is no easy way to do this in SQL because there are more than one thinAP object in the database.

4. it would be good if a TRAP action is to flag an AP as up and Down in the same way as an interface -- this would save polling for AP status from the controllers as frequently and improve responsiveness

(I've written a script and shared it on thwack to do this)

cobrien1

Thanks RichardLetts!

rajasekar

In our environment we are using many AP's more than 9k after many struggle we concluded solarwinds is not suitable for monitoring the AP's so we bought new monitoring aplication to monitor all the AP.

For example $:\$

200 Ap's connected in one switch if that switch down am getting 200 AP alerts and tickets and am not able to see the Down AP list more than 5 mins because WLC is fetching every 5 mins.

Is there any sufficent way to monitor AP's in solarwinds ???

FormerMember

I also find major deficiencies with Solarwinds wireless\ AP monitoring and alerting. Here are my wish list items that I know at least one competitor can do.

1. Client association by name. (Show the user name of the wireless client)

2. Client association history. (Answer these two questions: 1. What access points did a specific client connect to and at what times? 2. What clients were connected to a specific AP during a specific time?)

3. I find that in general, the historical data on Solarwinds is lousy. I see RSSI data for clients but can't report on that to identify trouble-spots or poor client equipment

4. Build dependencies between APs and switches.

ralexander

(Similar issue to RichardLetts #3 in his post)

We attempted to make Thin AP alerting work in our environment but in the end, had to disable the alerts as they were giving us false information.

We have HA Cisco controllers, monitored by both Orion and Cisco Prime Infrastructure.

We've been looking for more ways that Orion could work with thin APs so that we could potentially decommission Cisco Prime

Currently, Prime will tell us of down APs, even if they have disappeared from the controller(s).

To note, we do not add APs as ICMP nodes in Orion.

When Orion is configured to remove disappeared APs, the "down AP" alerts will not work - after the controller removes the AP, NPM polls the controller, the alert simply clears due to the AP object no longer existing.

With this method, the only way we know of a down AP is by looking at Prime.

When Orion is configured not to remove disappeared APs., the "down AP" alerts work as expected - the AP goes down, the alert is generated, the AP disappears from the controller, the alert remains operational.

The problem is when the AP comes back up.

Assuming it rejoins the same controller, Orion seems to give it the same Node.ID in the NPM database.

BUT if the AP joins another controller, either due to controller failover or other method, the AP gets a completely new Node.ID in the NPM database.

This causes the down alert to remain active as the AP has a different Node.ID to the one that generated the alert.

This can cause big problems if we had to failover a large amount of APs to another controller (bazillions of down AP alerts from one controller as it loses all it's APs)

It also causes a problem for the amount of disconnected APs residing in the Orion database since there's no easy way to clear them out.

RichardLetts

Awesome :-(

I've moved jobs to a cisco shop, and will be tackling this very issue in the next few months... i.e. redundant controllers, solarwinds, and cisco Prime... I was hoping this would not be a problem in this environment... so if Solarwinds can fix it for us, they will also fix it (probbaly) for Aruba.

guran84

I would agree to all the above.. We use all Cisco Wireless and had issues with the alerting on thin APs.

It needs to manage that an AP can move between controllers without causing a down AP, and another with the same name that shows as UP. Some sites have dual HA-Pairs of 5508 Controllers and sometimes APs are moved (we have wireless deployed in mines) which can cause an AP to be alerted as Down, but later join the other controller when it is taken online again.

A function to set wireless APs in maintenance mode (same as a node). This will help in the situation described above.

This will be sufficient for us at least on AP monitoring. We have Cisco Prime / CMX / ISE for all the client related troubleshooting (Cisco DNA soon, maybe )

Other more specific alerts from the WLAN controller could be triggered with syslog/traps maybe? But then that needs to be fixed asap, trap and syslog handling is not OK right now..

bouchm

Yeah some kind of solution to this issue would be great, it's very frustrating not getting accurate alerting on APs solely because they switched WLCs and it won't clear the alert.

ccie6145

I didn't setup our system, so I'm not sure if this is a capability issue or a configuration issue, but we are not being told by Solarwinds which AP has gone offline. We get alerts, that a ThinAP has gone down, if we click into them there is no info. When the AP comes back up, we are given a MAC address but not the AP name.

What we need is :

ThinAP L1-A53-PAINT1-3702 is down.

ThinAP L1-A53-PAINT1-3702 is up.

rschroeder

We've been relying on Cisco Prime for years; it does a robust job of configuring and monitoring AP's, as well as a very thorough job of heat mapping them. It's been our goto tool for AP's only, despite its ability to also manage switches & routers.

I appreciate NPM's ability to learn about AP's and create heat maps, but it doesn't manage/configure SSID's and zones and AP signal strengths, although it can monitor loads. It's not the tool for our 3000 AP's, sad to say.

josh.haberman

I organize all my nodes into groups (*cough* Orion Group management is HORRID *cough*) based on our physical locations.

This presents a problem with our 400+ Cisco WLC-based Thin APs. I want them to be present and viewable in the Group Summary Pages for these locations but, since Orion doesn't treat them as nodes I can't do this and haven't even found a good hacky workaround. Instead my users have to go to the separate Wireless Summary page to view wireless info.

I've been using this oldie but still very useful report: Cisco WLC LWAP Report (w/IP) (Here's the details courtesy of the Wayback Machine since the page is dead:Solarwinds WLC Inventory Report – Slashdoom ) as a supplement to get around the Wireless Summary's shortcomings.

As slash-doom mentioned in the archived page from 2015, the following is still true:

The AIRESPACE-WIRELESS-MIB doesnt seem to be fully accessible even through the new Wireless_AccessPoint tables introduced along with the HeatMap and LWAP Network Atlas improvements but we were able to pull in the information we were looking for via Universal Device Pollers.

That's my 2 cents.

cobrien1

Thanks josh.haberman!

bobmarley

We only use Solarwinds for up/down as ICMP Only nodes on ours. Cisco Prime for everything else.

bmallon

Yeah, we had to go with Cisco Prime to be able to monitor our APs more closely. SolarWinds is more of a chainsaw where Prime would be a scalpel. I'd much prefer to have a single place to monitor everything.

lmcbuilder

I monitor thin WAPs at the controller. DHCP WAPS are a major pain unless there is a DNS entry for them.

There is often an issue where an WAP leaves (disassociates) one controller for another. A script can poll to see if a WAP that has left one controller has gone to another.

marcrobinson

There is thread that I have been following for a couple of years on this topic.

Supressing Access Point (AP) Down Alert when the Controller is Down

I would agree that Thin AP's are difficult critters to nail down and any help would be very appreciated. I am looking at the alerts based on the disappearance events, but the ability to track the Thin AP's directly would be great.

lancesimpson

Did anything come out of this post? It's nice to know the Solarwinds team is interested in feedback, but I don't see any follow-up to the input that was provided.

cobrien1

No new functionality has been released to date as a result of this post. We are constantly researching areas where folks are having difficulties, but whether we move forward with those items depends on how much value we can deliver as compared to what we discover across all research items. In this specific example, we chose to invest cycles in web performance improvements, which came out with Orion Platform 2019.4 just a bit ago.

edwinhoekman

Hi Chris,

Any news on this post?

We are running 2019.4 HF1 and we are still having issues with the manageability of the Thin AP’s of our Cisco WLC’s.

The AP’s are sometimes are going down because of several different reasons. We cannot put an AP into an unmanaged state. So, these down AP’s are generating alerts.
These alerts on the Down AP’s are becoming annoying and we really would love to see more manageability for the AP’s (e.g. the possibility to change the maintenance mode to Unmanaged per individual AP).

Now we can only unmanage the complete WLC. And this is not preferable because you will unmanage the complete WLC including all AP’s.

Can you please give us an ETA on a solution on this issue?

Cheers,

Edwin

mesverrum

Chris left SW in Dec, so he won't be responding. I think the NPM PM is bhodi now.

Also, just to save you some heartache, nobody who works at SW will EVER give an ETA on anything, I imagine it must be drilled into them mercilessly when they get hired because they tend to be pretty on-message in that regard.