We are working on a customers setup, where they have issues with users dropping off at random times (probably not random...). And going over their setup, we told them to set their 802.1X reauthentication interval to 6011, multicast key to 1867, and unicast key to 1021 and turn on rotation of keys. All based on the Aruba design guide. Anyhow, in the Aruba documentation, it says to make sure these intervals are mutually prime, in other words they can only be divided by 1 or their value (6011/1=6011, 6011/6011=1).

Why is it that these values need to be mutually prime?

We have been asked to explain the values that Aruba recommends in detail, and I would love to know more but have not found details on these numbers or the prime thingy.

I am really only interested in understanding how these values play together, and the logic behind it. We already have an open Aruba support case on the random disconnected, so we won´t need to discuss the issues that prompted me to look at this.

Their disconnects issues started around the upgrade to 6.3 a long time ago (they are on 6.4.2.3 now), and they also upgraded from an MBC3600 controller to a Dell PowerConnect W-7210 controller.

We were looking into reauthentication and rotation of unicast/multicast keys, to see if this may assist with their issue. When a user drops off the wireless, they can be offline for up to 1-2 minutes. During that time they might not even see the SSID. But they do get reconnected automatically after the 1-2 minute mark.

On their backend Windows NPS/RADIUS server, we see about 10 entries for each client, where the last entry allows them access. I will gather more details from their RADIUS logs, but not until the end of the week when they are available.

I have a full copy of their controller configuration, just need to be sanatized before posting, if that is of value.

We have a TAC open, and currently waiting for customer to get a client debug log so that they can move forward.

Thanks for pointing out the possible issues that causes dropped connections etc.

To our knowledge the issues with instability/drops, seems to have started with the move to a 7210 controller and one of the first iterations of the 6.3 code. One of our major concerns is that they have not documented how the setup was prior to upgrading, nor what changes that could have been done during the life of the setup. Nor very detailed information about the many remote locations (480 access points), how many access points are close together. One thing that we did tell them, was to lower the signal strength as its set to 127. The argument from them to not change that, was that when a user drops who sat stationary only connected to one AP, it could not be signal strength. The problem there is that we do not have debug log data that shows the user actually only using one AP, and not been stuck on some other AP for a looooong time before moving.

Having access points with power too high creates contention and roaming issues, even when a client is not moving. The top power of an ap should match the output of clients to avoid that. That change will improve the experience of all clients.