Probe Suppression/Force Disassociation

[Joshua_Puusep]

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.

[Joshua_Puusep]

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.

[Jim_Seaman]

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?

[Joshua_Puusep]

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."

[Jim_Seaman]

I'm currently running 9.21.07 and I am having this very same issue. I've also enabled Fast Transition already under my VNS and still not seeing the clients roaming aggressively.

I know in Windows you can set the roaming sensitivity but that's not a solution for a mixed environment.

[Joshua_Puusep]

Thanks again for the input. I don't see the fast transition option in the privacy tab of my vns. I looked in the controller manual, and while it is listed as an option under the fields and buttons section, the privacy tab snapshot on page 232 does not show the option. I'm assuming that there is a prerequisite that we are not meeting.

I'm also not sure that 8011.r will address our issue. It is supposed to make roaming faster, but the client is still in charge. Our issue is not that the clients are roaming too slowly, but rather they are not roaming at all when there are better signal options available. Decreasing the cell size seems like the most viable option at the moment, unless the the probe suppression worked as intended 