Wireless AP Monitoring Enhancements

We have over 9000 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 fom 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.

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 4: Integrate LLDP data with the thin AP

1. e.g.

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

Nodeid

InterfaceID

4911

30

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.

We have over 9000 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 fom 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.

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 4: Integrate LLDP data with the thin AP

1. e.g.

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

Nodeid

InterfaceID

4911

30

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.