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

show ap association output

This thread has been viewed 7 times
  • 1.  show ap association output

    Posted Apr 29, 2013 12:49 PM

    I recently found the show ap association client-mac command and it's really great.  The only problem is that I'm not sure what a lot of the parameters mean and when I should be concerned about the values that are reported.  For example, here is a bit of the output:

     

    ------------------------------------------
    Parameter Value
    --------- -----
    Channel 157
    Channel Frame Retry Rate(%) 0
    Channel Frame Low Speed Rate(%) 0
    Channel Frame Non Unicast Rate(%) 0
    Channel Frame Fragmentation Rate(%) 3
    Channel Frame Error Rate(%) 22
    Channel Bandwidth Rate(kbps) 287
    Channel Noise 87
    Client Frame Retry Rate(%) 0
    Client Frame Low Speed Rate(%) 0
    Client Frame Non Unicast Rate(%) 0
    Client Frame Fragmentation Rate(%) 42
    Client Frame Receive Error Rate(%) 0
    Client Bandwidth Rate(kbps) 75
    Client Tx Packets 176931
    Client Rx Packets 71425
    Client Tx Bytes 27013166
    Client Rx Bytes 52906580
    Client SNR 29

     

    I understand SNR and channel noise, but I don't know at what point the channel frame fragmentation rate or error rate is too high.  I don't even know what sort of problems they're indicative of from a troubleshooting perspective.  Does anyone know where to find more information about all of these parameters and what values are considered high?



  • 2.  RE: show ap association output

    EMPLOYEE
    Posted May 05, 2013 08:25 PM

    Fragmentation is never really an issue.  You should start worrying when your clients start complaining ;)

     

    These statistics are only reported from the access point once per minute, so they are always a minute behind.  Individually, they don't really mean anything.  When they are paired with a larger issue, they are meaningful.

     



  • 3.  RE: show ap association output

    Posted May 16, 2013 12:41 AM

    I can think of one person that has issues daily.  He typically has great SNR (~35) but some of the stats look questionable, whether its high retransmits, fragmentation, or error rates.  There is zilch documentation on this, so I'm not sure how to interpret the stats when someone is having a problem.  I'm at the mercy of a local company that understand RF to a degree that I do not.



  • 4.  RE: show ap association output

    EMPLOYEE
    Posted May 16, 2013 01:04 AM

    The problem with explaining those statistics, is that they do not necessarily mean anything in a vacuum. Combined with certain client activity and behavior, they *could* be meaningful.

    The statistics are site specific as well as situation specific, so it is not easy to describe all of the combinations of these specific statistics and client behavior to give you anything meaningful. These statistics are most useful when paired with external analytics tools to find out what is really the truth. The truth is always somewhere between what the controller reports, what external tools report, client behavior and user experience.

    We could give you parameters for that output that indicate a client is having a great experience, but the user could say that things are sluggish.

    Is the problem:

    A driver on the laptop?
    An MTU setting on the wlan?
    Congestion on the controller port?
    Errors on the controller port?
    An application that is not efficient?

    None of the parameters in the output above will indicate that any of those are the problem, but they can realistically degrade the user experience. There is no replacement for the RF or wireless engineer that can look at all sides of an issue and determine which parts contribute to the exact issue that is being observed. Those engineers also have developed methods over years to determine the cause of issues and as new clients and applications come out, they have to relearn how to be efficient in dealing with issues, while keeping in memory old ones.

    With that being said, people who CAN use the output of the command above know what it is for and use it. There are others who do not know, and if the parameters are explained to them and are just taken as face value, could lead them down a time consuming and faulty path to the truth.

    I can say for a fact that many parameters are explained to users, but require a lot of time to fully understand the real impact or utility of those commands. Some users also put too much weight on the output of commands and fail to see the true importance in the big picture of monitoring and performance.

    The way to possibly get the best information about the output of commands and specific information relative to your install is to speak to the engineers at your local company who will be able to tie the portions of your output to specific client behavior at your facility.... With all the caveats out of the way, here is the breakdown of that command:

     

    Channel 157  - The Channel the client is on
    Channel Frame Retry Rate(%) 0   - What percentage of traffic on that channel observed by the access point is retries
    Channel Frame Low Speed Rate(%) 0   - What percentage of traffic on that channel observed by the access point are operating on the lowest frame rate
    Channel Frame Non Unicast Rate(%) 0    -  What percentage of traffic on the channel observed by the access point is non-unicast or brodcast and multicast
    Channel Frame Fragmentation Rate(%) 3  - What percentage of traffic on the channel observed by the access point is fragmented
    Channel Frame Error Rate(%) 22   - What percentage of traffic on the channel observed by the access point transmitted is errors.  There are quite a few reasons why this would occur and the devil is in the details.  You would have to compare historical errors to this number to determine if you are having a bad day or a good day.  In addition, you would want to corroborate this number with a packet capture, because these counters are from the access points' point of view.
    Channel Bandwidth Rate(kbps) 287  - The bandwidth on the channel as observed by the access point
    Channel Noise 87  - The Noise on the channel observed by the access point
    
    The parameters below are all duplicates of the parameters above, except they are client statistics, as observed by the access point:
    Client Frame Retry Rate(%) 0
    Client Frame Low Speed Rate(%) 0
    Client Frame Non Unicast Rate(%) 0
    Client Frame Fragmentation Rate(%) 42
    Client Frame Receive Error Rate(%) 0
    Client Bandwidth Rate(kbps) 75
    Client Tx Packets 176931
    Client Rx Packets 71425
    Client Tx Bytes 27013166
    Client Rx Bytes 52906580
    Client SNR 29

     Again,

     

    These numbers are from the perspective of the access point, not the client:.

     

     Just because the access point can see the client at 29 SNR does NOT mean that the client can see the access point at the same signal strength.  You could have an access point with good receive sensitivity, but the client is not able to properly hear the frames to decode them, or it might have local issues that they are dealing with.

    The Channel noise parameter could be anywhere within the radius of the access point.  A spectrum analysis tool and a packet capture taken at the location of the client would give the other side of the picture as to what the client is observing.  For example if there is an interferer that is close to the client, but NOT close to the access point, the access point might not see it as an issue, but it is causing client problems.

    The non-unicast rate is important for the client side as well as the access point side.  If this number is high (50%) and is sustained, it could indicate that there are broadcasts (beacons, multicast and broadcast traffic) that is dominating the air and it should be remedied.  The solution to that *could* be to drop broadcast and multicast at the Virtual AP and/or VLAN level of all of your access points as well as "Deny Broadcast Probe Requests" on the SSID level to limit wifi as well as application level broadcasts, which most of the time consume critical bandwidth.

    The retry rate is important, because if sustained at 50% or more, it could indicate severe congestion.  Again, these parameters only update from the access point as frequently as once per minute, so it could take quite a few minutes to determine if any parameters is sustained.  Also, wifi traffic occurs in bursts, so one thing measured one minute could be completely different another minute.

     

    Sorry for the long post...  It is simply not possibly to convey the true importance of a command's output in a few words without giving you proper perspective.  That is probably why many commands are not explained to this level of details...

     



  • 5.  RE: show ap association output

    Posted May 17, 2013 10:32 AM

    Thanks for taking the time to explain this.  I feel helpless at times when clients report wifi issues and the client stats I see look suspicious, but I can't even begin to explain what the problem could be.  I wish there were more definitive answers with RF, but that also makes it interesting.