1 Reply Latest reply on Aug 14, 2014 4:14 PM by patrick.mchenry@loves.com

    Wireless AP Improvements

    RichardLetts

      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

      awampApName

      L100.OFFICE.AP01

      APName

      awampAPFirmware

      6.3.1.5

      APFirmware

      awampAPModel

      AP 105

      MachineType

      awampAPMFG

      Aruba

      Vendor

      awampEventAPICON

      ICON

       

      awampEventGroupMonURL

      xxxxx

       

      awampEventGroupMngURL

      xxxxx

       

      awampGroupName

      Academic Campus APs

      Custom Property?

      awampEventAPMonURL

      xxxxx

       

      awampEventAPMngURL

      xxxx

       

      awampAPEthMAC

      3643.3A46.333A.3746.3A43.433A.3338.3A36.45

      AP MAC address

      (note the

      awampEventAPIPOld

      a.b.c.d

      Old AP IP address – used to check if the AP has moved.

      awampAPIP

      w.x.y.z

      New AP IPAddress

      snmpTrapOID

      AWAMP-MIB:configAlert

       

      sysUpTime

      0.10 second

       

       

      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

      awampAPIP

      w.x.y.z

      IP address to find the AP (see above)

      awampEventDescription

      Device: UMSW.3.43 - xxxxx : Device Down Minutes Down Threshold > 5 minutes.

       

      awampEventSeverityCode

      1

       

      awampEventID

      2

       

      snmpTrapOID

      AWAMP-MIB:downAP

       

      sysUpTime

      0.10 second

       

       

      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.

       

      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.