Cisco Wireless AP Modes

Hello Cool

Sniffer mode is used to capture Layer 2 wireless frames and send them to a packet analyzer program such as Wireshark. In this mode, the AP will actively receive frames, and process them, and send them to the configured packet analyzer. There they can be saved into .pcap files (for Wireshark) for examination at a later time.

SE-Connect mode is different, in that it is used to perform spectrum analysis. The AP will “listen” to the RF band in the air and record the frequencies and wavelengths it “hears”. This is useful in discovering all of the sources of EM radiation within range, that may affect the performance of the wireless network. In this mode, no actual transmitted data is examined.

Strictly speaking, Sniffer mode functions in Layer 2 (Data Link) while SE-Connect functions in Layer 1 (Physical).

I hope this has been helpful! Stay healthy and safe!



Thank you, yes this makes perfect sense.

1 Like


I’m reading the Official Cert Guide CCNA 200-301 by Wendell Odom as well as reading your content online. This section really confuses me because it’s divided into two parts.

There is a section where you mention Repeater mode, Workgroup Bridge, Outdoor Bridge and Mesh Network (and by the way, they are all referred to as ‘Non-Infrastructure mode’ in the book). However, the only similarity here is Bridge mode being similar to Outdoor Bridge mode and Mesh Network mode. Are they different names to mean the same thing or are they somehow different?

Furthermore, the Official Cert Guide states the following: “Many Cisco APs can operate in either autonomous or lightweight mode, depending on which code image is loaded and run. From the WLC, you can configure a lightweight AP to operate in one of the following special-purpose modes:” and then they go on explaining all the modes mentioned in the topic of this forum, but the book also separates the four listed modes mentioned above to an earlier chapter. And how come they only mention Lightweight APs and not Autonomous APs in being able to use these special-purpose modes?

After listing the modes, the chapter ends with this note:

“Remember that a lightweight AP is normally in local mode when it is providing BSSs and allowing client devices to associate to wireless LANs. When an AP is configured to operate in one of the other modes, local mode (and the BSSs) is disabled.” Does this mean that there are no BSSs in other modes apart from local mode?

Looking forward to hearing from you as I’ve been looking for answers for hours now.


Hello Joshua

I understand your confusion, and I believe this has to do with the use of the term “modes”. Unfortunately, it is used to describe multiple things.

First of all, an AP can either run as an autonomous AP or as a lightweight AP (notice I didn’t use the word mode?). The first means all the intelligence of its functionality is contained within the device itself, the second means that the intelligence runs in the wireless controller on the network or in the cloud. Whether you use lightweight or autonomous has to do with the deployment model you are using, and you can find out more about that here:

Now, each of these deployment methods have their own modes. An autonomous AP can also be considered an AP in a non-infrastructure deployment. In other words, it doesn’t function as part of the network infrastructure, all of its network functionality is contained within the device itself.
Those APs that run in autonomously can be configured to function in one of the “non-infrastructure modes” as listed in the book, as well as in this lesson:

(Now the book includes Mesh as a non-infrastructure mode, however, Rene describes it as another type of deployment model, which makes more sense to me.)

Finally, for those access points running in a lightweight deployment, they too can be configured to function in any one of the AP modes, as listed in this lesson:

So to sum up, there are two deployment models, autonomous and lightweight. Each has its own list of modes:

Autonomous (non-infrastructure):

  • Repeater
  • Workgroup Bridge
  • Outdoor Bridge


  • Local
  • Monitor
  • FlexConnect
  • Sniffer
  • Rogue Detector
  • Bridge/Mesh
  • Flex plus Bridge
  • SE-Connect

Mesh is a special case that the book considers non-infrastructure, while others (including Rene) consider it simply a third deployment model.

I hope this has been helpful!



Thank you so much Laz, that’s an excellent explanation and answers nearly all of my questions!

I just have one clarification to make. I’m now trying to list the deployment models and modes that provide BSSs so let me know if I am incorrect:

Deployment models with BSS:

Autonomous AP
Mesh AP (Since a Mesh AP uses a BSS on one channel for client association while using another for the backhaul network of traffic between Mesh APs

Lightweight AP Modes with BSS:

Local Mode (Would you consider this to be both a deployment model and a mode?)

So a total of 3. Is that correct?


Hello Joshua

A BSS is used whenever clients connect to the access point to obtain connectivity. This is the case in the following modes:

  1. Repeater - since end-user clients connect to the repeater, then a BSS is used. In this case, the repeater is simply retransmitting the BSS from the AP it is repeating from, essentially extending it.
  2. Outdoor bridge - even though it doesn’t connect end users, it is still an AP to client architecture, where the clients are simply one (point to point) or more (point to multipoint) fixed stations. So even in this case, a BSS is used.
  3. Local - This is the most common mode, where users simply connect, so a BSS is used.
  4. Mesh - for the same reasons you mention in your post.

Local mode is simply another way to refer to the default mode of the lightweight deployment model, and not a deployment model itself.

I hope this has been helpful!



Amazing, thank you so much!

1 Like

Does the rest of the mode except for the monitor mode emit SSID??
Can I use the wireless network in Rogue Detector, Sniffer, and Bridge mode?

Hello YongHun

The Monitor, Sniffer, and SE-connect modes don’t support wireless clients, and thus do not broadcast an SSID.

An AP in Rogue Detector mode can do both rogue detection and connect clients based on its configuration. In this mode, the AP divides its time between servicing clients and discovering and attempting to disable rogue APs. More info on this can be found here.

Bridge mode will broadcast an SSID, but may or may not be able to support wireless clients at the same time. If the AP has one radio, then it is used solely for the purpose of the bridge. If it has more than one radio, then one radio can be used for the bridge while the other can be configured to connect clients.

I hope this has been helpful!


for an L-AP in Flex-Connect mode is considered to be set a trunk between the SW and the L-AP?
I presume so, in case it will serve multiple SSIDs ?!?!

Thank you.

Hello Sorin

Yes, you could configure an AP in FlexConnect mode to be connected to the switch via a trunk. This is standard practice in order to be able to serve multiple SSIDs as you mention.

I hope this has been helpful!



Hello Laz

Thank you for the reply.
My curiosity is if a Light-AP has to have a Trunk to be allowed in FlexConnect mode? Or a Trunk is simply optional and only if it serves multiple SSID’s?

Hello Sorin

First of all, just a clarification. An Access Point can be in either Light-AP mode or FlexConnect mode, it cannot be both.

When you configure an AP to function in FlexConnect mode, you can either use an access port connection or a trunk port connection. It is not mandatory to use a trunk unless, as you say, it is serving multiple SSIDs. More info on this can be found here:

The same is true about a local mode AP. You can either use an access port or a trunk port. But in both local and FlexConnect cases, if a trunk is used, the access point needs IP connectivity on the native VLAN.

I hope this has been helpful!


1 Like

Hello Laz,
and thank you!

I think I have to dig deeper cause I can’t get my head around these AP modes, Trunks, and Tunnels.
As I understood (until now) a Light-AP can be set to work in one of these modes [local, FlexConnect, Bridge…]. but not that the Light-AP is actually another mode.

Anyway, I have to dig more.

Thanks again for your reply.

1 Like

Hi Rene,
actually I have deployed WLC as virtual Machine and the only mode you Can configure is FlexConnect. and I configured SSID Vlan Mapping using the WLC and then I routed the traffic to FW. the wireless traffic (DATA ) will not go to WLC through CAPWAP tunnel. so there is no Encapsulation for Data traffic . APs only added vlan Tag to the Frame based on the SSID-Vlan Mapping.

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!


1 Like


Can someone please help me understand the following?:

  1. “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.

  1. 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?

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!



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?:

  1. 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).

  1. EWC APs are NOT a CAPWAP APs, but the APs that use an EWC AP as their WLC are CAPWAP APs.

  2. 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.

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!


1 Like