Cisco Wireless AP Modes

lagapidis · May 16, 2023, 5:24am

Hello Ammar

First of all, the virtual WLC has some limitations compared to a physical WLC, and one of those limitations is the supported feature set. With a vWLC, you can only configure access points in FlexConnect mode, as you mentioned. This means that other modes such as sniffer, monitor, or rogue detector are not available.

Secondly, you are correct in stating that when using FlexConnect mode in a virtual WLC, the data traffic is not tunneled back to the WLC through CAPWAP. Instead, the traffic is switched locally at the access point (AP), which is a key feature of FlexConnect mode. This can be advantageous in reducing latency and conserving bandwidth.

Since you’ve routed the traffic to a firewall, it should be configured to handle the different VLANs and apply the necessary security policies to each. This setup enables local switching at the AP level and ensures proper traffic segregation based on VLANs, with security policies applied at the firewall.

I hope this has been helpful!

Laz

molnarattila1221 · December 30, 2023, 4:29pm

Hello,

Can someone please help me understand the following?:

“FlexConnect is an AP mode for situations like the one above. The AP can locally switch traffic between a VLAN and SSID when the CAPWAP tunnel to the WLC is down.”

Isn’t it the case that the Lightweight Access Point (LWAP) uses only the CAPWAP control tunnel, but never the data tunnel, as the LWAP forwards user traffic locally? It looks like that’s what the OCG is saying:

I’m just confused because the article makes it sound like forwarding user traffic locally between a VLAN and SSID pair is an optional thing, instead of being mandatory.

I don’t understand why the book says that LWAPs have access links to switches (instead of trunks), and that user VLANs don’t have to exist on access switches:

I can see why this would be the case with an LWAP in local mode, but how does this work if the LWAP is in FlexConnect mode? How can the FlexConnect LWAP forward traffic between multiple SSID/VLAN pairs if there’s no trunk link between the LWAPs and the access-layer switches, and the VLANs don’t exist on the access-layer switches? I’m confused because the book made a categorical statement about all LWAP modes, however it looks like that statement isn’t true for all LWAP modes. Am I misreading something?

I’ve read the comments in this thread, and it looks like only those FlexConnect LWAPs must be connected via trunk links to switches that serve multiple SSIDs. However, if a FlexConnect LWAPs serves only a single SSID, it can of course be connected via an access link. But I still find it strange that the OCG seems to say otherwise, so I want to double-check.

Can someone please help me clarify these questions?
Attila

lagapidis · January 4, 2024, 11:31am

Hello Attila

I think the problem here is in the explanations in each case. Let me try to clarify:

First of all, just to clarify, a Lightweight AP is any AP that is using a WLC. LWAPs can use multiple modes, which define how they operate. So, a FlexConnect and a Local AP are both LWAPs.

Now, a Local AP will always use the CAPWAP tunnel for both control and data traffic. A FlexConnect AP will always use the CAPWAP for data traffic, and will switch data traffic locally to reach the Internet. The text as Rene has written it is a bit misleading. It should read:

“The AP will always locally switch traffic between its own SSID and a local VLAN to reach the Internet (and other networks), even if the CAPWAP tunnel to the WLC is down.”

In the OCG, it considered “forwarding data normally” as forwarding data independently from the CAPWAP tunnel. Does that make sense?

Whenever you use a CAPWAP tunnel in local mode, and you send all data and control traffic to the WLC, you can do so for multiple SSIDs, so in the scenario in the diagram (local APs) this is doable.

However, for FlexConnect cases, you can only do this if you have mapped all of your SSIDs to the same local VLAN. If not, then you must use a trunk for local switching to take place. This scenario is not specified in the OCG, and it may just be an unfortunate omission. However, you are correct in your understanding. This NetworkLessons note also sheds more light on the switchport mode for FlexConnect APs.

I hope this has been helpful!

Laz

molnarattila1221 · February 29, 2024, 12:12pm

Hello,

I’m having trouble wrapping my head around these concepts. Can someone please confirm if this is correct?:

Are these all the options and the correct relationships for local mode, FlexConnect, EWC, and autonomous APs?:

CAPWAP AP = the AP has either:

(a) only a control CAPWAP tunnel (Flexconnect) to a WLC, or
(b) both a data and a control CAPWAP tunnel to a WLC (local mode).

EWC APs are NOT a CAPWAP APs, but the APs that use an EWC AP as their WLC are CAPWAP APs.
Autonomous APs are NOT a CAPWAP APs, and no APs can use them as their WLC.

So basically, this:

Maybe the only small correction would be that “WLC” can mean both

(a) a device that can act as an AP and WLC (so an EWC), as well as

(b) a device that can only act as a WLC, but not serve any wireless clients (so what we usually call a WLC).

So instead of “WLC,” a more precise term would be something like “device that serves the role of a WLC.” But this small diagram is meant to give a quick overview. Also, the option after the first “No” makes this relationship clear, but please correct me if I’m wrong.

Thank you.
Attila

lagapidis · March 2, 2024, 6:07am

Hello Atilla

This is an interesting approach to categorizing the wireless AP modes that are available. You’re doing it based on whether or not an AP terminates a CAPWAP tunnel. Whe you use the term “CAPWAP AP” it is somewhat ambiguous. I assume you mean an AP that terminates a CAPWAP tunnel AND serves wireless clients. You’ll see shortly why this distinction is important.

You are indeed correct that the Local Mode and the FlexConnect mode terminate CAPWAP tunnels, where the former sends both data and control traffic over the CAPWAP, while the FlexConnect sends only control traffic.

Also, the autonomous and EWC APs indeed don’t terminate CAPWAP tunnels (although the EWC does create CAPWAP tunnels as it plays the role of the WLC).

The approach you used is good, and it does clarify how and when a CAPWAP tunnel is used, however, it doesn’t cover all possibilities. There are other modes that use the CAPWAP tunnel, albeit somewhat more discreetly, and in a specialized manner. For example:

Bridge mode - These APs use CAPWAP tunnels for control traffic to the WLC. Data traffic may be locally switched or sent through the controller based on the configuration.
Monitor mode, rogue detector mode, and SE-connect mode - These are special modes that don’t serve wireless clients but are used for monitoring, security, and spectrum analysis. All three use CAPWAP tunnels to report back to the WLC.

So each of these modes leverages CAPWAP tunnels as well, for efficient management and control of wireless traffic between the APs and the WLC, although the specifics of what traffic is tunneled depends on the specific mode.

As for your final comment about the WLC, you are correct that:

However, the term WLC does not necessarily refer to the physical device (such as a 3504 WLC for example), but it refers to the software processes that operate as a WLC, regardless of what device or “box” those processes run in. Just like when we say “a DHCP server” and not “the device that serves the role of the DHCP server” even though a DHCP server can be a physical server, a PC, a switch, a router, a firewall, or a Raspberry Pi. Does that make sense?

I hope this has been helpful!

Laz

molnarattila1221 · March 9, 2024, 1:56pm

Hello Laz,

Thank you again for the thorough and clear answer.

Yes, the term "CAPWAP AP” is somewhat ambiguous. I’ve heard and read others use this term, though, so I didn’t come up with it (but some people seem to refer to the commands starting with “capwap ap”, and not as an AP mode). For example:

https://mrncciew.com/2013/03/17/ap-registration/ ,
https://semfionetworks.com/blog/convert-a-cisco-capwap-ap-to-a-mobility-express-ap/
https://www.simweb.ch/blog/2020/11/dtls-1-2-and-cisco-lwapp-capwap-aps-on-shooting-yourself-in-the-foot/

(By the way, I noticed you can get rid of the site preview if you put a character after the link. This makes it tidier.)

I’ve now revised my diagram in light of your response plus the information in the ENCOR book:

Do I assume correctly that the non-client serving AP modes have only control CAPWAP tunnels to the WLC? That seems to be logical, since the CAPWAP data tunnel is used for client data, which is not something that APs in these modes deal with. Hence, no need for a CAPWAP data tunnel for them.

I am still confused by the book, though. Can you please help?

Page 599:
" Because the data and management VLANs may need to reach every autonomous AP, the
network configuration and efficiency can become cumbersome as the network scales. For
example, you will likely want to offer the same SSID on many APs so that wireless clients
can associate with that SSID in most any location or while roaming between any two APs.
You might also want to extend the corresponding VLAN (and IP subnet) to each and every
AP so that clients do not have to request a new IP address for each new association."

But isn’t this the same problem with FlexConnect APs as well? The only way FlexConnect APs could switch data locally is if those conditions are met which the autonomous APs require. But the book to me makes it sound like ALL lightweight APs (LWAPs) have the benefit over autonomous APs that there isn’t this need to reconfigure the network each time there is a change.

Also, on page 600:

" As a “lightweight” device, a Cisco AP loses its self-sufficiency to provide a working BSS for
wireless users. Instead, it has to join a WLC to become fully functional. This cooperation is
known as a split-MAC architecture, where the AP handles most of the real-time 802.11
processes and the WLC performs the management functions"

Again, a categorical statement about all LWAPs. But, FlexConnect APs don’t need to join a WLC to become fully functional. It needs no CAPWAP data tunnel, and even if its CAPWAP control tunnel is down, it can still serve clients.

So all of this leads me to believe that either I don’t understand these concepts fully, or the book didn’t address these questions with the most complete accuracy. All I care about though is to understand the content.

Can you please help?
Have a nice weekend.
Attila

lagapidis · March 12, 2024, 6:19am

Hello Attila

The diagram looks good, I think it covers all of the possible options.

Although it is true that there is no wireless client data, there is still data (non-control data) being sent from these devices, such as monitoring information, or sniffed traffic. So strictly speaking, there’s still a distinction between control and data plane traffic. However, for the purposes of these APs performing these roles, it may be that this traffic is considered management traffic, and may be sent over the control tunnel. I have been unable to find any documentation to support either case. I believe the only way to definitively find out is to do a packet capture to examine the actual traffic.

Not quite. What the text is saying is that if you want to have the same SSID appear on all of your APs, you need to span the VLAN that corresponds to that SSID throughout your network. As the network grows, this becomes very inefficient and cumbersome. VLANs should typically be confined to as few access switches as possible. So the two design aspects may come into conflict. The issue with FlexConnect is different. That has to do with switching user traffic locally, and control traffic via the WAN (communication with the WLC).

Again, not quite. A lightweight device is defined as one that has a CAPWAP tunnel. In other words, it is an AP that cooperates in some way with a WLC. All AP modes (including FlexConnect) are lightweight, except for autonomous APs which are not considered lightweight. Also, it may be possible to set up a bridge mode or a mesh mode without a WLC (depending on the AP model) which would also make those not lightweight.

Concerning FlexConnect, it is indeed considered lightweight even though it can function in the event that the connection to the WLC is lost. It requires the WLC, at least initially to operate, and if the connection is lost, its configuration cannot be modified until that connection has been reestablished. Does that make sense?

I hope this has been helpful!

Laz