Hello, can someone confirm for each of these roaming scenarios in AOS v8 what 802.11 packets are exchanged during the roaming process - e.g. 802.11 re-auth/assoc only, 802.11 re-auth/assoc + 4-way handshake, 802.11 re-auth/assoc + full EAP exchange + 4-way handshake. Thanks!
1. No fast roaming technology enabled, client roams from AP1 to AP2 on the same controller.
2. No fast roaming technology enabled, client roams from AP1 to AP2 on different controllers in a cluster.
3. OKC/802.11r enabled, client roams from AP1 to AP2 on same controller.
4. OKC/802.11r enabled, client roams from AP1 to AP2 on different controllers in a cluster.
I don't have the full answer for your question, however I can explain some of the mechanics of client traffic, which may help you understand what is happening a little better.
When a client sends a frame to an AP in a non-cluster environment, the client takes the data, encrypts it, and puts it in an 802.11 frame and transmits it to the AP. When the AP receives the frame, assuming the SSID is forwarding client traffic using tunnel mode (generic routing encapsulation [GRE] mode, which is the typical forwarding mode used on Aruba networks), the AP will put an 802.3 header on that frame, encapsulating the 802.11 frame inside the 802.3 frame, and forward it to the controller. When the frame arrives at the controller, the controller then unencapsulates the frame, extracts the L2 source and destination addresses, unencrypts the frame, and then processes it in the controller firewall (assuming PEF license is installed), and then forwards the frame according to the firewall rules and where the frame is going.
If the client roams from one AP to another AP, with both APs connected to the same controller, when the client roams to the 2nd AP, the AP performs the same task, and the client traffic is handled by the controller in the same way and processed through the same firewall, with firewall state being preserved.
If the client roams from on AP to another AP that is connected to another controller (in a non-cluster environment), when the client roams to AP2, the AP will perform the same process, and forward the frame to the second controller. The process will be the same, however the firewall state is not preserved or shared between the two controllers.
In a cluster environment, let us say that it is a 4 node cluster, meaning 4 controllers, or in ArubaOS 8 terminology, 4 mobility controllers (MC). So the 4 MCs are named MC1, MC2, MC3, and MC4. For your question, we can ignore what happens with the APs, and only need to focus on what happens with the client traffic.
When a client connects to an AP, the client is assigned what is known as a User Anchor Controller (UAC) and a Standby User Anchor Controller (S-UAC). In this example let us say that MC1 is the client's UAC and MC3 is the client's S-UAC. The UAC assignment is not actually passed on to the client, but is passed on to all of the APs (I'll explain the S-UAC later). The UAC tells every AP that if this particular client connects to any AP, the client traffic is to be tunneled to the UAC, MC1 in this example, using the same tunneling logic explained earlier. So this means that no matter what AP the client connects to, assuming the AP is part of the cluster, the user traffic is always forwarded to the same controller. So from a logic and firewall state perspective, the user is always connecting through the same controller, maintaining the same firewall state.
The only time this will change, meaning, the only time the user traffic would be directed to a different controller, is if the client's UAC (MC1 in this example) were to go down or become unreachable.
So what happens if the MC1 goes down. As I stated previously, there is a standy, S-UAC, for each client. When the client connects to the UAC, the top 10 firewall sessions are copied between the UAC and the S-UAC. So, if the station is connected to an AP, the AP tunnels the client traffic to MC1. MC1 mirrors the firewall states with MC3 (again, using this example). If MC1 goes down, when the AP attempts to send the user traffic to MC1 and realizes that it can't, the AP instead, forwards the user traffic to the client's S-UAC, which is MC3. The traffic arrives at MC3, as tunneled traffic, same as explained previously, and ultimately MC3 unencapsulates and unencrypts the traffic, and goes to forward it though the firewall on MC3, and since the firewall sessions were mirrored, the client experiences a stateful failover from one controller to another.
I know this does not answer your question, but hopefully makes you understand the process better so that you can either answer your question yourself, or make you understand the process better when discussing it with someone else.
I hope this helps,
Hey Dave! Ah not what I was looking for unfortunately :-). I'm more curious about the 802.11 auth packets exchange.
We need more information for a complete answer. You mentioned AOS8, but is the controller(s) clustered or standalone? Is the forwarding mode for the VAP tunnel or decrypt-tunnel?
Hello Charlie! I'm looking at tunnel mode for all 4 cases, and clustered controllers for scenarios 2 & 4. Single controller for scenarios 1 & 3. Thanks!
@neil-b wrote:Hello Charlie! I'm looking at tunnel mode for all 4 cases, and clustered controllers for scenarios 2 & 4. Single controller for scenarios 1 & 3. Thanks!
My apologies for missing the cluster/standalong distinction in your question at the beginning.
As David mentioned in his response, these use cases will be similar packet flows. Ultimately, this is because of how clustering works, and the user session being "anchored" to an active controller. Whether roaming from AP1 to AP2 on the same controller or on different controllers in a cluster, the user's 802.11 session is active on a primary controller. Tunnel mode forwards all 802.11 frames to the user's anchor controller for encrypt/decrypt, so PMK (and related derivatives) is retained on the controller.
802.11r's primary benefit would in other environments, such as bridge or decrypt-tunnel mode where a single controller is not responsible for the client's encrypt/decrypt function. In that case, the controller is able to distribute keys to the APs to facilitate fast roaming, with that 802.11 process now occuring on the AP rather than the anchor controller.
Thanks Charlie! I guess the part that's not clear to me is that when the client moves between APs, it'll have to do an 802.11 authentication/re-association at the very least. So is what you're saying that for all 4 scenarios only an 802.11 auth/re-association will be done, kinda like this package capture screenshot below? I know this would happen for scenario 3 with 802.11r, but with OKC it may need to do a 4-way Handshake too.
Details aside for fast roaming technologies, would there be a full EAP auth done during roaming for scenarios 1 & 2 where fast roaming technologies are disabled/unsupported by the client? In my mind, the client would still have to do full EAP if they don't support fast roaming technologies, even in a cluster, cause the cached PMKs won't be relevant right?
If the client does no form of PMK caching/roaming at all ... no OKC, etc, then yes it would be a hard roam with fulll EAP exchange.
At Aruba, we believe that the most dynamic customer experiences happen at the Edge. Our mission is to deliver innovative solutions that harness data at the Edge to drive powerful business outcomes.
© Copyright 2021 Hewlett Packard Enterprise Development LPAll Rights Reserved.