Probe Suppression/Force Disassociation

  • 0
  • 1
  • Question
  • Updated 2 years ago
  • Answered
I've been playing with Probe Suppression/Force Disassociation to see if it could help in certain area's with clients that do not roam aggressively, however it does not seem to be working.  e.g. I have an ap with 16 clients on it, 4 of which have -80 RSSI.  When i enable probe suppression, force disassociation with a threshold of -65, none of the 4 clients get disassociated.  Any advice?  Thanks much.
Photo of Joshua Puusep

Joshua Puusep

  • 2,254 Points 2k badge 2x thumb

Posted 2 years ago

  • 0
  • 1
Photo of FES

FES

  • 1,360 Points 1k badge 2x thumb
Joshua, 
you must be in 9.21.07 or 9.21.08 version that solves the probe suppresion bug. Also you can use the min rate to 11 mbps and disable 802.11b clients.
Photo of Joshua Puusep

Joshua Puusep

  • 2,254 Points 2k badge 2x thumb
FYI 802.11r is only an option if your wlan is using WPA (not WPA -PSK).

If your testing probe suppression, make sure you are are verifying roam activity by looking in Netsight>Wireless>clients.  We were originally looking at the Clients By AP reports on the controllers and after working with GTAC, it seems that is not a reliable to determine the active clients.  See GTAC's note below:

"After discussion with some of my colleagues as well as the wireless developers, we determined that the client reports are not actually a list of currently connected clients. These are actually showing the currently authenticated clients, regardless of whether the client is actually connected to an AP.

Because of this, once a client is disconnected by force disassociation, it will stay in the report for 30 minutes, assuming the session timers are set to defaults."
Photo of Jim Seaman

Jim Seaman

  • 314 Points 250 badge 2x thumb
I was using other applications on the client, not the controller report view, and still saw a serious delay in roaming.

What did you use to verify the fast roaming was occurring if you weren't using the controller reports?
Photo of Joshua Puusep

Joshua Puusep

  • 2,254 Points 2k badge 2x thumb
We are not using fast roaming (802.11r) in our environment.  Fast roaming was designed to speed up the key exchange for mobile users when roaming.  Since we are using WPA-PSK,  there is no key exchange when roaming.

For us, the question became how to verify the force disassociation threshold was working.  You can verify client association by looking in the Wireless>Clients view in Netsight, or by using 3rd party software on the client itself, such as Acrylic or even Ekahau.

One caveat that is not stated in the manual, found in https://gtacknowledge.extremenetworks.com/articles/Solution/Issues-with-clients-staying-with-an-Acce... , is that the client will be disassociated 5dBm below the disassociation threshold.  So if you set the threshold to -70, the system will disassociate clients at -75.  Hope this helps.
Photo of Jim Seaman

Jim Seaman

  • 314 Points 250 badge 2x thumb
Wow. That's crucial to know in my opinion. Thank you for the information!
Photo of Sai Prasad Rao Rapolu

Sai Prasad Rao Rapolu

  • 1,494 Points 1k badge 2x thumb
Hi  FES


I have Probe supression enabled with RSS: -65  , min rate of 6 mbps  and  disabled b clients  (only using g/n)  is it fine ?
Photo of Joshua Puusep

Joshua Puusep

  • 2,254 Points 2k badge 2x thumb
I was on the phone with GTAC last week troubleshooting something unrelated to probe suppression.  One of the things they wanted me to verify was that probe suppression was not enabled, as there is apparently a current known bug.  we are running firmware 10.11.02.0032 on our controllers.  I didn't ask any further questions since we are not currently using it, however maybe someone from extreme can confirm in this post.