AP FLAGGED STATUS

  • 1
  • Question
  • Updated 6 days ago
  • Answered
We detected most of our AP with Flagged status. This status happened randomly with random APs. The Flagged type is AP health high connection failure flag. Code 330.
Do anyone has any idea why this issue can occurred and how to solve it.  
Photo of Nadia

Nadia

  • 3 Posts
  • 0 Reply Likes

Posted 3 months ago

  • 1
Photo of Jardel Almeida

Jardel Almeida

  • 37 Posts
  • 3 Reply Likes
I find it interesting to share the AP / WLC GUI status print.

However, generally these flags are related to overhead, it is necessary to change the channel if the environment is dense, inserting static channels of 2.4GHz, and limiting the 5GHz to 40MHz.
Change the RF configuration to beamform, and change the study period of frequencies / neighboard / interference to 1h (3600 s); Also check the load / user balance, and if you prefer, reduce the power of the AP to 1/3.
Photo of Nadia

Nadia

  • 3 Posts
  • 0 Reply Likes
Should try this. Thanks for the suggestions:)
Photo of David Buhl

David Buhl

  • 8 Posts
  • 11 Reply Likes
We found the same issue and reported it to Ruckus (along with a LOT of other issues with vSZ).  They have so far not resolved it, but said it is probably related to them over-reporting connection failures.  For us, if you go to the Dashboard and Connection Failures, we see 70-85% failure rate overall, with the same for the first category of "Authentication".  The other categories: Association, EAP, Radius, DHCP, are all below 1% almost all the time.  We have 2500 clients, and they all are connecting fine now.  If 80% of them weren't connecting, I think someone might tell me.

So Ruckus is mis-reporting, or mis-categorizing something.  The definition of "Authentication" from the Dashboard is: Authentication failure is a measurement of client connection attempts that failed at the 802.11 open authentication stage. This is the first stage in any modern Wi-Fi connection.

My guess is that our clients are roaming and start a connection, but don't complete it with that AP, but instead have moved on before it can complete the connection.  But that still seems like it can't explain all of this, because wifi should connect fairly quickly, and our people walk (slowly, especially when I'm behind them in the hallway) around, and really shouldn't be passing to many APs without connecting to them before moving to another AP.
Photo of Jim Michael

Jim Michael

  • 43 Posts
  • 11 Reply Likes
Just chiming in that we are seeing the EXACT same behavior as David describes. I have a vSZ with four zones, and entire system was running fine on 3.5 (no authentication failure flags, APs were only flagged when something was flag-able like really high client counts, etc).

Then two weeks ago I upgraded the vSZ to 3.6.2.0.222 and only upgraded ONE zone, and it immediately started flagging almost all APs with a "connection failure health [100] because it crossed the threshold [30]" event...so the system is saying that my APs are having *100%* client connection failure, when everything is obviously working fine (people would be screaming and I'd have tons of monitored ipads and printers and such offline if that were actually happening.)

The other three zones that are still on 3.5 continue to operate normally (no false flagging.) I haven't had the guts to upgrade to 5.x yet to see if it's fixed there, as that seems like such a different beast... but it's REALLY frustrating to see all these false flags on my zone because it's hiding any REAL issues I'd be interested in.

Please acknowledge and fix this, Ruckus!
Photo of Michael Brado

Michael Brado, Official Rep

  • 2722 Posts
  • 379 Reply Likes
It might be helpful if you open a ticket and provide your logs to the engineer.
Photo of Jim Michael

Jim Michael

  • 43 Posts
  • 11 Reply Likes
Will do!