7 Replies Latest reply on Oct 15, 2018 11:25 AM by RichardLetts

    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!

        • Re: Your Thoughts on Thin AP Alerting?


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


          • Re: Your Thoughts on Thin AP Alerting?

            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)

            1 of 1 people found this helpful
            • Re: Your Thoughts on Thin AP Alerting?

              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 ???

              • Re: Your Thoughts on Thin AP Alerting?

                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.

                • Re: Your Thoughts on Thin AP Alerting?

                  (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.