Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Show AP Stats

Is there a good reference in how to interpret the "show AP stats" command? 

I have a new (online for 15 days) 1142 listed below.  It is the first 802.11n AP I've deployed.  The stat counters look bad (TxFragment Count = TxFrameCount, RetryCount > TxFrameCount).  But I don't know how to put it all together to say "here are the stats, this is the problem".  I see TxFrameCount, but no corresponding RxFrameCount, so it is hard to calibrate some of the errors.  Any help would be appreciated.  I'm running code 5.2.193.0 (and can't upgrade right now) on a WiSM.

----------------------------------------------------------------------------------------

>show ap stats 802.11b <AP Name removed>

Number Of Slots.................................. 2
AP Name.......................................... <removed>
MAC Address...................................... 00:22:bd:<removed>
Radio Type....................................... RADIO_TYPE_80211b/g
Stats Information
  Number of Users................................ 5
  TxFragmentCount................................ 926078
  MulticastTxFrameCnt............................ 65328
  FailedCount.................................... 403683
  RetryCount..................................... 1642858
  MultipleRetryCount............................. 13639
  FrameDuplicateCount............................ 0
  RtsSuccessCount................................ 0
  RtsFailureCount................................ 0
  AckFailureCount................................ 690010
  RxFragmentCount................................ 0
  MulticastRxFrameCnt............................ 110664
  FcsErrorCount.................................. 21455258
  TxFrameCount................................... 926078
  WepUndecryptableCount.......................... 93
  TxFramesDropped................................ 503
--More-- or (q)uit
Call Admission Control (CAC) Stats
  Voice Bandwidth in use(% of config bw)......... 0
    Total channel MT free........................ 0
    Total voice MT free.......................... 0
    Na Direct.................................... 0
    Na Roam...................................... 0
  Video Bandwidth in use(% of config bw)......... 0
  Total num of voice calls in progress........... 0
  Num of roaming voice calls in progress......... 0
  Total Num of voice calls since AP joined....... 0
  Total Num of roaming calls since AP joined..... 0
  Total Num of exp bw requests received.......... 0
  Total Num of exp bw requests admitted.......... 0
  Num of voice calls rejected since AP joined.... 0
  Num of roam calls rejected since AP joined..... 0
  Num of calls rejected due to insufficent bw.... 0
  Num of calls rejected due to invalid params.... 0
  Num of calls rejected due to PHY rate.......... 0
  Num of calls rejected due to QoS policy........ 0

4 REPLIES
Cisco Employee

Re: Show AP Stats

Hi d_p_grant:

No, there's not a clear, modern one all polished and tailored for the Unified Wireless Network products.  There's an oldie but goodie

Error Statistics on the Cisco Aironet 340 Series Bridge

http://tools.cisco.com/squish/55528

that goes through the various types of RF related stats, what they mean and offers some suggestions on troubleshooting.

Keep in mind

  • wireless is a half-duplex, acknowledged medium
  • statistics are only relevant over time, so if you don't know when "clear stats " was last run, there's not much value for a specific incident
  • here at OSI layer 2, units of communication are frames, and that if there's too much data to fit into a single frame, that data will be broken into multiple frames or fragments
  • when the RF environment is clean and the channel is available (i.e. nobody else is talking,) stations can pretty much transmit when they want to;  if there's a lot of activity, stations will begin using RTS/CTS to "raise their hands" to receive a chance to transmit.  

In making the connection to the Error Stats doc

  • FailedCount is describing what the doc calls Holdoffs
  • RetryCount is describing what the doc calls Retries
  • FcsErrorCount is describing what the doc calls CRC Errors

The fact that there are so many FcsErrorCount in relation to all the other statistics implies that the radio is receiving a lot of packets that are failing the CRC check.  Assuming that the sender was smart enough to calculate the CRC correctly when the frame left the sender's antenna, and that the receiver is smart enough to do the CRC check correctly when it received the frame on its antenna, the corruption must be happening while the frame is in the air (interference.)

The Cisco Spectrum Expert can help you see what's in the air and what's interfering with your wireless network.


http://tools.cisco.com/squish/70EF4

Sincerely,

Rollin Kibbe

Network Management Systems Team

New Member

Show AP Stats

MAC counters doesn't make sense, anyone can shed light on some of them (RetryCount TxFragmentCount RxFragmentCount?

For example, according to several sources:

RetryCount: This counter shall increment when an MSDU is successfully transmitted after one or more retransmissions.

TxFragmentCount: This counter is incremented for an acknowledged MPDU with an individual address in the address 1 field.

That is, TxFragmentCount includes all successful transmissions (sucess at first transmission plus success after one or more retransmissions). RetryCount only counts successful transmissions that required retransmission. Then, why I see RetryCount > TxFragmentCount? It makes no sense. Also, why RxFragmentCount = 0, when I know for sure that more than one frame (single fragment) has been successfully received?

Bug on IOS? Wrong counter definition? Should RetryCount be the total number of retransmissions of successfully delivered fragments?

Show AP Stats

Hi Faramir,

First, I have to admit I like topics and questions like yours. It opens discussion and in the process there always is a learning opportunity for something new ...

Based on face value of this string of post and without looking at other outside resources I will give my 2 cents on the subject based around my expereince with 802.11 frame work which should tie into these counters.

RetryCount -

We know from the frame control field of a 802.11 frame there is retry bit. This bit is a 0 or 1. When it is a 0 this means that this frame is the first to be sent. If the bit is a 1 its means the client didnt receive an ACK from the receiver and the client is sending the frame again. All counters I have looked at always count EACH frame with the rety bit set to 1. So if a client sent the same frame 100 times and 99 were retires there would 99 in the Retry counter ..

TxFragmentCount -

We know from the frame control field of a 802.11 frame there is a MORE FRAGMENT bit. When this is set to 1 this means there are other frames in sequence to comlplete the MPDU. Each frame, will require its own ACK just like a normal frame. When the last frame in the series is sent the more bit will be 0. This will indicate to the reciver this is the last of the framted MPDU.

In my expereince radios when seeing the more bit flipped to 1 .. it adds 1 to the TxFragment Counter ..

Make sense?

__________________________________________________________________________________________
"Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin
__________________________________________________________________________________________
‎"I'm in a serious relationship with my Wi-Fi. You could say we have a connection."

__________________________________________________________________________________________ "Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin ___________________________________________________________
New Member

Show AP Stats

Hi George,

Thanks for your reply! Some more discussion:

RetryCount -

All counters I have looked at always count EACH frame with the rety bit set to 1. So if a client sent the same frame 100 times and 99 were retires there would 99 in the Retry counter ..

That's what I suspected. If this is the case, definition of RetryCount should be revised accordingly. However, this wouldn't be consistent with another counter: MultipleRetryCount (frames successfully retransmitted after more than one retransmission attempt). If you only take retry bit into account, how to distinguish between frames that were retx once, from frames retx more than once?

TxFragmentCount -

In my expereince radios when seeing the more bit flipped to 1 .. it adds 1 to the TxFragment Counter ..

No, it doesn't make sense (in my case). The fragmentation threshold is set above the MTU, and hence I never see frames with More flag activated, but TxFragmentCount >> 0. It seems that TxFragmentCount is increased after any txed frame (even when it is the only fragment and More=0). This is consistent with the reported TxFrameCount (which equals to TxFragmentCount).

The problem is in RxFragmentCount, which is 0 in most cases.

I'm afraid that the problem is related to CSCtx60459 (you can google it). Something that may have been solved in latest WLAN Controller version (I have an older 5.2.193.0).

1936
Views
0
Helpful
4
Replies