Security

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.

 

Thank you,

-Petter

petter@firstpoint.no,

 

Where is this documented?

 

Found it here: http://www.arubanetworks.com/techdocs/ArubaOS_64_Web_Help/Content/ArubaFrameStyles/802.1x/Advanced_Configuration_O.htm

 

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.

 

Thanks

-Petter

By default unicast and multicast key rotation is disabled.  And, by default those numbers are within those thresholds.

 

You typically would not enable key rotation in a normal network.  The article says "if you do enable it".

 

There are quite a few reasons for random disconnections and key rotations should stay disabled so that it does not contribute to the disconnections.

 

How long have you had random disconnections?

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.

 

Thanks

-Petter

- The configuration is not really useful, because it says how a network *should* perform, and not how it is performing.

- The tech-support is the most useful, but it is (1) too hard to sanitize (2) sanitizing removes crucial information needed to get to the bottom of your issue

- There are many things that could cause disconnects and multicast key rotation is disabled by default, so that is normally not the issue

- If the customer had the problem before the upgrade, then the ArubaOS code is not to blame

 

Here are the reasons for disconnects, in order:

 

- Too much AP density, which creates alot of co-channel interference (power needs to be lowered on access points)

- Using the wrong channel-bonding configuration (40 and 80 mhz channel bonding typically should not be used in high density areas)

- Not turning on Broadcast filtering (broadcasts are useless, but they cause congestion and disconnects).

- Broadcasting too many SSIDs (broadcasting SSIDs increases contention and co-channel interference.  More than 4 SSIDs is too much)

- If the problem occurs with only specific clients, those clients might need to have their wireless drivers updated.

 

You should open a TAC case, if you have not already because it can be a single complicated issue, or a combination of complicated issues.  Key rotation is normally not the culprit.

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.

 

Anyhow, thanks for super quick replies.

 

-Petter

#7210

Glad you have a case open.

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.

How do we close or end a thread?

There is some good information is this thread, although not the answer to the question.

 

-P

We can leave this thread open and you can update us on your progress until it is solved.