3 of 3 people found this helpful
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)
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 ???
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.
4 of 4 people found this helpful
(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.
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.
1 of 1 people found this helpful
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..
2 of 2 people found this helpful
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.
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.
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.
1 of 1 people found this helpful
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.
We only use Solarwinds for up/down as ICMP Only nodes on ours. Cisco Prime for everything else.
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.
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.
There is thread that I have been following for a couple of years on this topic.
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.