Wireless AP Improvements

We have over 9200 aruba wireless access points; they all have two controllers: a primary controller and a secondary controller. Right now the thin wireless access points are non-sticky. What I mean by this is that if the WAP cannot be found on a controller then it is deleted from the orion database, along with all of its history. It also looks as if a WAP changes from its primary to its backup controller (e.g. when we upgrade a controller) then it may disappear from the old controller and move to its new controller, again deleting the WAP and its associated data. According to the WAP table we have (had) over 109,000 thin wireless APS on campus. This is obviously not true.

I've spent some time plugging wireless APS in and out of the network, looking to see what alerts are being generated, and what happens in the two management platforms we have for APS (Aruba Airwave, and Solarwinds Orion).

The non-sticky behavoir of APS in Orion is creating a significant issue, to the point where I might as well not be using it to monitor APs. e.g. if an AP is down and its controller reboots for some reason, the solarwinds deletes the WAP from its database and its alert clears. I now have a down WAP with no alert or even indication that it ever existed (all of the historical data about the WAP goes away too)! I feel this is actually a bug and will open a case on this shortly.

there are two ideas that I think encapsulate these changes, please vote them up.

http://thwack.solarwinds.com/ideas/2689

http://thwack.solarwinds.com/ideas/1719

thanks

=====================

Change 1: Provide a management interface to thin wireless access points.

1. Management state (up/down/unmanaged)
2. They can only be deleted by the UI or API (they are not deleted automatically)
3. Custom properties
4. Add a primary and secondary controller address so the same AP can be  associated with more than one controller

Effect:

                History for APS would not be deleted automatically

Change 2: Integrate with Aruba airwave AWAMP-MIB:configAlert traps

Create or update thin WAP entity with properties

In Aruba installs without Airwave then this information could be populated when an AP is found on a controller and updated that way.

Change 3: Integrate with Aruba airwave AWAMP:downAP and AWAMP:upAP traps

This should set the thinAP status to up or down, allows Orion to be more responsive

Change 4: Integrate LLDP data with the thin AP

1. e.g.

SELECT NodeID, LocalPortNumber FROM Orion.NodeLldpEntry where RemoteSystemName ='UMSW.3.43'

The NODEID is sufficient to provide a link to the device this AP is plugged into; note: this is not the controller node for the AP, this is the switch it’s plugged into.

The interfaceID is sufficient to link to the interface (in NPM), or the port (in UDT)

Effect: it often useful with APS to toggle the port state they are plugged into – this effectively power cycles the AP and reboots it, which may be sufficient to restore service.  This would speed up the process to find that interface.

Aside: xxxxx represents a https URI -- the editor will not let me post documents that contain URI, only URL; this is what has broken the ability to post XML snippets.