1 of 1 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.
1 of 1 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.
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..