So, I'm interested to hear how others are using Soalrwinds NPM to do monitoring of access points, be they thin or be they not It seems to me there are at least a couple of approaches depending on technology in use, configuration and noise generated.
Some of the options that I see are: (for ease of typing, where I say monitor then presume it will also alert)
Monitor the IP of every AP as its own node, and also monitor the interface it is attached to. Can generate a lot of alert noise and multiple alerts per single AP going down.
As for 1, but only monitor the AP as a direct IP (node). Can reduce the noise (quantity) of alerts
Only monitor the interface, and rely on being able to poll the WLC for up / downs. Possibly the best (?) compromise but would still generate two alerts per every down.
Only monitor the up/downs from the WLC if they are Thin APs. Ignores the physical interface the devices are connected to, reduces noise but makes identifying the interface hard if documentation is not accurate.
A combination of all the above. Monitor the AP as a node, monitor the interface, and alert on traps. This clearly would be the noisiest in terms of alerts.
-- ++ --
I'm sure there are other options I'm not immediately seeing but talk to me.
Tell me what your approach is as I'm inetrested to hear?
Let me also give you a scenario that may or may not help responses:
A client has >4000 Thin APs managed via a WLC but due to configuration the actual IP of each device is not visible except from or through the GUI of the WLC. Due to the nature of the setup, Solarwinds also sees every device twice as different SSIDs appear on different WLC's.. Solarwinds is seeing the Thin AP up / down traps and the physical interafces where the device is patched is monitored (but not consistently). To assist troubleshooting a weekly report is run that generates a "show CDP Neighbor" (sic) outpt for all switches - however this is not without its own pitfalls including not picking up on incorrectly deployed APs. To cap it all, the clients end users constantly move APs around for various reasons, and there is no central listing of where each AP is meant to be physically installed.
So I guess two immediate questions:
I monitor and alert on about 2,000 APs. I use the option #2 you described and just monitor each AP as an individual node. My alert is set up like this:
we have a custom property called "TimeZone" applied to each node so we aren't receiving alerts at 7AM EST (when our NOC opens) for a store on the West Coast where it's 4AM there. this works best for us because our stores don't even open till 8AM EST.
As with many things in monitoring, the route you go down very much depends on your use case, and also on the sensitivity that the wireless clients have to wonky APs.
Your option #3 is the way to go for most environments, in my experience, but it you don't have a lot of redundancy in your mesh, you may way to include monitoring each AP directly as an ICMP node as well, so you can ensure you get your hot spares deployed ASAP.
Combining those would give a pretty reliable setup.
>> Combining those would give a pretty reliable setup.
Whilst reliability is always good to consider, in this case I am purely looking at the mechanics of how best to approach the above scenario> This is in mind with the constraints we have, and wanting to reduce the noise whilst minimising troubleshooting issues.
Sadly, in this cse, monitoring the end node (AP) by ICMP is not possible.
Option 4, I monitor about 60 Aruba Virtual controller AP's via SNMP each having Thin AP's ranging from 8-30 nodes. Orion can list them all in the Wireless section and show me Clients, MAC's etc..
>> Option 4, I monitor about 60 Aruba Virtual controller AP's via SNMP each having Thin AP's ranging from 8-30 nodes.
My personal, preferred approach is this but my scenario is based on Aruba kit with which we have a lot of niggly issues. I believe a lot of our problems stem from the person that introduced and configured the WLCs not really understanding, and so was learning on the fly. He then set them live and promptly left the company!!!
As a consequence, as I mentioned, we have APs appearing twice due to different SSID's being on dfferent Aruba controllers - this may be as expected but we don't know. Second main issue is we can't direct SNMP monitor them (2,000 odd) anyway, due to some configuration approach taken on the controllers. If it makes a difference, the controllers are 7200 series.
Originally I used option 3 but then when Orion came up with the Thin AP alert out of the box, I started using it. I did modify the trigger status to be not equal to up. Worked beaut for disconnects but if an AP was disconnected for a long time, I would not receive a reconnect email.
I use option #2 in conjunction with network scans. I manually import any AP's, routers, switches, etc, back into SolarWinds. If they already exist then they are skipped. If they are new they are added.
Several of the tools in our security suite perform scanning. I just subscribe to the reports and import them frequently. You could use Orion's discovery as well.
SolarWinds solutions are rooted in our deep connection to our user base in the THWACK® online community. More than 150,000 members are here to solve problems, share technology and best practices, and directly contribute to our product development process.