Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Expand all | Collapse all

Clarifiation On Arm Channel Change Reasons

This thread has been viewed 2 times
  • 1.  Clarifiation On Arm Channel Change Reasons

    Posted Sep 26, 2012 11:36 AM

    Higher Ed Campus deployment, ~950 APs.  Not using DFS channels.  Getting a lot of channel changes in 5GHz.  Started crunching data from SNMP traps (since there isn't an easy way that I've found to report on *all* channel changes):

     

     wlsxTrapAPARMChangeReason.0: armEmptyCh(12)112
     wlsxTrapAPARMChangeReason.0: armErrorThresh(10)242
     wlsxTrapAPARMChangeReason.0: armInterference(8)

    123

     

    Looking for a little clarification on what ARM determines as cause.

     

    armInterference - If memory serves me - this is 802.11 co/adjacent channel interference; and is cited as a cause when interference index thresholds are crossed.  I believe my ability to "tweak" this setting is in the ARM profile in the "Free Channel Index", which is the delta between interference index between channels before it changes channels.  Can someone confirm I've got this right?

    armErrorThresh - My understanding here is We've met the configurable "Error Rate Threshold" (default 50%) for a configurable interval (default 30 seconds).  So this is the heavy hitter in my environment - meaning relatively - lots of PHY errors over 30 seconds at a time.  Is it fair to assume that these errors would be caused by both wifi AND non-wifi interference sources?  I know there is another configurable channel change cause in armNoiseThreshold which I am not seeing.

    armEmptyCh- I get why this happens.

     

    Thanks for helping clear some of this up. I know I've got some non-wifi interferers out there, and student have rouge access points... I'm trying to narrow in on which is having a more signifigant impact on things.

     

    Kevin



  • 2.  RE: Clarifiation On Arm Channel Change Reasons

    EMPLOYEE
    Posted Sep 26, 2012 11:45 AM

    Please see the ARM supplement document here:  http://support.arubanetworks.com/DOCUMENTATION/tabid/77/DMXModule/512/Command/Core_Download/Default.aspx?EntryId=2569 for details.

     

    If you want to see why an access point changed channels, the "show ap arm history ap-name <name of ap>" command will show you.  If you have Airwave and are running 7.5.x, it will also show you the ARM history changes for all your APs.

     

     



  • 3.  RE: Clarifiation On Arm Channel Change Reasons

    Posted Sep 26, 2012 12:02 PM

    Colin-

    Thanks, I'll take a look at the supplement.

     

    I knew of the other ways to find ARM history; however I am fighting these issues over a large number of densely deployed buildings.  It would be great if I could get an arm history table for all active APs, rather than having to iterate through each AP.

     

    Airwave is almost the same deal.  If I want to see ARM history I have to drill into each AP.  If I want to see classified non-wifi interferers, I have to drill into each radio profile - I don't even have a really good way from a custom report to list all Channel Changes across multiple APs or groups over a given interval; or detected interferers across multiple APs over a given interval.  It's a bummer, because I know the Airwave DB has all of the info I'm looking for.

     

    At this point, I'm parsing through SNMP channel change traps in airwave, and doing a lot of excel work to parse the message field of the trap...  Perhaps these are reasonable feature requests for both AOS and Airwave?



  • 4.  RE: Clarifiation On Arm Channel Change Reasons

    EMPLOYEE
    Posted Sep 26, 2012 12:11 PM

    One approach is to start in Airwave is the RF Health Report.  With that you can see the devices with the most interference, the most ARM changes, the most users, etc.  That will give you an idea of your worse problem areas, instead of having to parse through all the traps.

     

    After you do that, once you find that problem AP, you will want to go to the radio with the problem and look back as far as possible and see if, user count, noise, interfance has always been a problem or did it just occur recently.  That will give you a good starting point.

     

    You can also optionally re-run the RF health report and constrain it to a folder and even change the top 10 worst access points to something like 20 so you can get a more full sampling.

     

     



  • 5.  RE: Clarifiation On Arm Channel Change Reasons

    Posted Sep 26, 2012 01:32 PM

    I have been through this approach.  For a while I was under the impression I was seeing non-wifi interference on a specific channel.  Since not all APs in a given area would have been on the band to scan at the time of interference, it was hard to track down specific

    sources without manually iterating to through each radio interface. 

     

    It would have been supremely helpful to issue a "sho ap arm history ap active" (or something like this) with a correlated list of arm events for all active APs.

     

    Airwave RF Health reports only indicate frequency of interference events.  I was chasing down a "video fixed frequency" classified interferer across many buildings on my campus.  I would have loved a report from airwave that showed all reported video fixed frequency ionterferer classifications/starttime/endtime/rssi/classifying AP during a single interval.  Since my APs keep changing channels, it is difficult to determine specific trends of interferers on specific channels over time.



  • 6.  RE: Clarifiation On Arm Channel Change Reasons

    Posted Sep 26, 2012 01:34 PM

    But most importantly; did I get my interpretation of the channel change reasons right in my original post?



  • 7.  RE: Clarifiation On Arm Channel Change Reasons

    EMPLOYEE
    Posted Sep 26, 2012 04:46 PM

    Those are correct, in general, yes.