An Access Point, as defined by 802.11, can take a packet out of thin air and convert it to ethernet and has the ability to do all the stuff it needs to do to make it all happen. That’s called an “Autonomous” or “Standalone” AP.
The standalone AP is great but it doesn’t scale very well. Then along come a way to better scale. The controller architecture (split-MAC they called it) and the “lightweight” AP.
Important: It’s not dumb or thin, it’s lightweight, in the same way other protocols were written to a portion of the spec and called the “lightweight” variant of that protocol.
A lightweight AP only does the real-time stuff an “AP” is supposed to do and the controller does all the non-real-time stuff.
The glue that holds the AP to the controller is an IETF standard protocol called CAPWAP.
For this lightweight architecture, an AP grabs packet out of thin air and then only does real-time stuff to it. Encryption/decryption is a good example of real-time stuff an AP does. It then takes that 802.11 packet and puts it in to a CAPWAP envelope and sends it to the controller.
The controller then converts the 802.11 packet to 802.3 (Ethernet), applies the correct policy, and puts it in the right VLAN.
This is the default operational mode of a lightweight AP and it’s called “Local Mode” which also can be called “Connected Mode”.
But what if you have a bunch of small branch offices with just a few AP’s each. You:
- don’t want the expense of controllers in each location (or the management burden) and you
- don’t want your print-job to go from your mobile device, all the way across your WAN, just to make a U-turn and come back across your WAN and print to a printer you’re physically 5 feet away from.
Flexconnect changes how packets are processed by allowing the AP to convert the 802.11 packet directly in to Ethernet and placing it on the VLAN that is trunked to the AP. This takes the controller out of the data path, even though the controller is responsible for firmware updates, configurations, RRM, and IPS. This default behavior of Flexconnect is called FlexConnect Local Switching.
Please keep in mind there are constraints you need to consider before using Flexconnect. See the Restrictions on Flexconnect section of the configuration guide.
Now for the “flex” in FlexConnect.
For some SSID’s you may want to change the data path. For example maybe you want all your employee traffic to stay at a branch but you want your guest traffic to go back to the controller for inspection.
So for that SSID you can use FlexConnect Central Switching. For this SSID (WLAN), it will act like a Local Mode AP, but for other SSID’s (WLANs) it’s in Local Switching.
Data Path vs. Authenticators
The other thing to consider is where 802.1x RADIUS authentications will take place. By default it uses central authentication, you can also select local authentication. These are options in the FlexConnect for how 802.1x authentication is done. Even though you may select local or central switching, all 802.1x authentication, by default, is done by the controller.
So what if the controller goes away? Well then your 802.1x authenticator goes away. Unless you have local authentication configured. If you select local authentication for your FlexConnect AP, then you need to configure your AP as a RADIUS authenticator, which includes telling your RADIUS server about that AP and setting up a RADIUS key.
For more information refer to the FlexConnect section of the Configuration Guide. Here is the link if you’re using version 8.3 code. To find the configuration guide for the code version you’re running, click here.