Cisco CUWN over a WAN link (FlexConnect vs. local mode)

As long as there is H-REAP or FlexConnect, I wondered if there are any differences between a local mode AP and a FlexConnect AP configured for central switching (over the WLC). Obviously there is, because there are some Cisco recommendations regarding this topic as:

“Cisco does not support deploying local mode APs using a centralized WLC over a wide area network. If remote APs need to be supported over a WAN, Cisco recommends implementing the FlexConnect architecture.”
(Source: Mobility Design Guide [1])

That means, if there is some kind of WAN (MAN as well?! 🙂 ) between the WLC and AP you should deploy FlexConnect.

If there are requirements to deploy a centrally switched network at the WLC (because there is a centralized security infrastructure like firewalls), you can deploy FlexConnect central switching (default). But again, what are the actual functional differences between FlexConnect central switching/central authentication and local mode APs? The most obvious aspect here is the split MAC architecture. In the default mode of operation (local mode) some 802.11 management tasks are performed directly by the AP, some are performed by the WLC. The split MAC architecture is explained here (https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-5/Enterprise-Mobility-8-5-Design-Guide/Enterprise_Mobility_8-5_Deployment_Guide/cuwn.html?bookSearch=true#45944).

So the theory is, that the split MAC functionality is altered for FlexConnect. To test this, I build a small test environment:

I put a box between the AP and WLC to simulate WAN delay. This can simply be implemented using a Linux client with two interfaces. The Linux “bridge-utils [2]” are needed to bridge two network adapters together. This way a layer-3 transparent box can be placed in the traffic path. Of course the simulation itself would work without the “bridge-utils” as well, but by using “bridge-utils” you don’t have to care about routing. To simulate a round-trip time of 300ms, the one way delay of 150ms must be configured on each adapter

tc qdisc add dev root netem delay 150ms
tc qdisc add dev root netem delay 150ms

If I ping the AP from my central site (same site as the WLC), I can verify the results:
$ ping 172.16.255.149
PING 172.16.255.149 (172.16.255.149) 56(84) bytes of data.
64 bytes from 172.16.255.149: icmp_seq=1 ttl=255 time=300 ms
64 bytes from 172.16.255.149: icmp_seq=2 ttl=255 time=300 ms
64 bytes from 172.16.255.149: icmp_seq=3 ttl=255 time=300 ms

The following scenarios were tested.

To verify the impact of the simulated delay, I captured on the wireless side to get the 802.11 management frames. To determine if the AP or WLC generated a certain type of management frame, the time between a request and the corresponding response frame must be considered.

• If the time between a request and response frame is ~300ms (WAN RTT), the WLC is responsible to process these type of frames.
• If the time between a request and response frame is ~0ms, the AP is responsible to process these type of frames.

I applied a display filter to reduce some noise (ignore Beacon and Acknowledgement frames):
(!(wlan.fc.type_subtype == 0x0008) ) && !(wlan.fc.type_subtype == 0x001d)

WAN RTT of 0 ms (simulation disabled)

The first three scenarios are just for reference testing, that everything works as expected. The time between request frames and corresponding response frames is very fast, because there is no significant delay between AP and WLC (the “time” columns is set to “seconds since previous displayed packet”). So there is no chance to determine (except debug outputs on the WLC and AP), which component handles which frames. It doesn’t really matter if the AP is in FlexConnect mode or in local mode.
Example (Probe, authentication, association process and 4-way handshake):

As expected, there is no significant delay between a request and corresponding response frame.

Now let’s introduce a RTT of 300ms between AP and WLC:

WAN RTT of 300 ms with a local mode AP

As documented in the split MAC architecture documentation,  the probing and the assocation process is directly handled by the AP (no delay). Furthermore (as expected), the Association response is generated by the WLC and therefore there is one RTT of 300ms between the Association request and response frame.

We can ignore the 802.1X PEAP part, because the authentication server is on the central site – we have always a delay here for the SSL packets.

The 4-way handshake (“Key message x of 4”) is interesting again. The PTK negotiation (message 1 and 2) for WPA2 unicast frames is directly performed by the AP. The third message containing the broadcast and multicast key is sent by the WLC. Therefore there is one RTT of 300ms between the second and third message in the WPA2 4-way handshake.

Just for completeness. The whole process from probing until the fourth message of the 4-way handshake took ~4,7 seconds with 300ms RTT. Of course the EAP part took the most time.

WAN RTT of 300 ms with a FlexConnect central switching mode AP

So the capture for FlexConnect centrally switched traffic looks nearly the same. However you’ll see, that this time there is no delay between the association request and response frame. This is an indication, that the FlexConenct AP is directly handling this type of traffic. Everything else is more or less the same compared to the local mode APs.

This behavior is the same for FlexConnect centrally or locally switched traffic.

Summary:

The main difference between local mode APs and FlexConnect APs regarding the 802.11 split MAC architecture processing is that the FlexConnect AP handles (re-) association response frames directly. So in theory, there is a reduction of one WAN RTT for the whole process.

However, this is only small part of the whole story. Some of you might think, that there is no benefit using FlexConnect in a centrally switched environment – but this is not necessarily correct, because of:

• Some clients might be very sensitive to delays between association request and response resulting in a complete WLAN assiciation failure or unpredicive behavior (see footnote 1)
• AP connected via WAN is FlexConnect if you want to follow Cisco validated design and if you want to follow a supported solution
• Fast roaming (802.11r) is directly handled within a FlexConnect group for “DS-over-the-air”. So with local mode, there would be one WAN RTT delay for fast roaming. I guess it’s the same for OKC.

Test equipment and tools:

• WLC 2504 (8.3.140.0)
• AP: AIR-CAP3502I-E-K9
• Client: Sony Xperia Z1 compact

Footnote 1: I testet it one time using an RTT of 1 seconds. My smartphone (sony z1 compact) didn’t have a problem with this. However, there might be other clients, which won’t be happy with it.

Sources:

• [1] Mobility Design Guide 8.5: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-5/Enterprise-Mobility-8-5-Design-Guide/Enterprise_Mobility_8-5_Deployment_Guide.html
• [2] Bridge-utils Debian documentation: https://wiki.debian.org/BridgeNetworkConnections