Describe Cisco Wireless Architectures and AP modes

From one access point to hundreds

An access point (AP) is the device that turns wired Ethernet into Wi-Fi. It has one or more radios (2.4 GHz, 5 GHz, and on newer models 6 GHz) and an Ethernet port. Wireless clients associate with the AP, and the AP bridges their frames onto the wired LAN. Domain 1 covered the radio side (channels, SSIDs, RF). This section is about how the APs themselves are built and managed, because the answer changes completely when you go from one AP in a coffee shop to five hundred APs across a campus.

Three architectures exist:

1. Autonomous APs – each AP is a complete, standalone device configured individually.
2. Lightweight APs with a Wireless LAN Controller (WLC) – APs are “thin” and a central controller does the thinking. Also called split-MAC or controller-based.
3. Cloud-managed APs – such as Cisco Meraki, where the management plane lives in the vendor’s cloud and the APs forward traffic locally.

Autonomous architecture

An autonomous AP (also called a “fat” or standalone AP) contains all the functions needed to run a WLAN by itself: it advertises SSIDs, authenticates clients, encrypts traffic, chooses its own channel and power, and bridges frames to the wired network. You configure it through its own CLI or web page, exactly like a small switch. Cisco autonomous APs run a version of IOS.

Because each SSID usually maps to a VLAN, an autonomous AP with several SSIDs connects to the switch on a trunk port so it can tag each SSID’s traffic with the right VLAN. The AP also needs a management IP in one of those VLANs.

The problem is scale. With 200 autonomous APs you have 200 devices to configure, 200 places to change a password, and no coordination between neighbors: two adjacent APs may pick the same channel and interfere, and a client roaming from one AP to another must fully re-authenticate. Autonomous APs are fine for a home or a small office and are used in some outdoor bridging scenarios, but not for enterprise campuses.

Lightweight (split-MAC) architecture with a WLC

In the lightweight architecture, the functions of an AP are divided between the AP and a central Wireless LAN Controller (WLC). This division is called split-MAC because the 802.11 MAC-layer functions are split in two:

Anything that must happen in microseconds stays on the AP; anything that benefits from a network-wide view moves to the WLC. The AP does not even store its configuration; it downloads everything from the controller when it boots. This means one WLC can manage hundreds or thousands of APs, all APs get the same policies, channel plans are coordinated automatically, and a client can roam between APs without re-authenticating because the WLC already knows it.

Key terms for lightweight APs:

• Lightweight AP (LAP or LWAP): an AP that depends on a WLC. Most Cisco enterprise APs (Catalyst 9100 series, Aironet) run lightweight code.
• CAPWAP: the tunneling protocol between AP and WLC (next section).
• WLC: a physical appliance (Catalyst 9800-40, 9800-80) or a virtual machine (Catalyst 9800-CL), or embedded software in a switch or AP.

CAPWAP tunnels

CAPWAP (Control And Provisioning of Wireless Access Points, RFC 5415) is the protocol a lightweight AP uses to talk to its WLC. It creates two tunnels over the IP network between each AP and the controller:

The word “tunnel” means the AP wraps the original frame inside a new IP/UDP packet addressed to the WLC. This has an important consequence: in the default local mode, all client traffic goes to the WLC first, even if the client is talking to a printer on the same switch. The WLC unwraps the frame and places it on the correct VLAN. Because everything is tunneled, the AP’s own switch port only needs the AP’s management VLAN, which is why a lightweight AP connects to an access port (see 2.7).

CAPWAP runs over IP, so the AP and WLC do not have to be in the same VLAN or even the same building. The AP finds its WLC by several methods: a DHCP option (option 43), DNS (CISCO-CAPWAP-CONTROLLER.localdomain), a local broadcast, or a controller address previously stored on the AP. Once it finds a WLC it authenticates using X.509 certificates, downloads its configuration and (if needed) a matching software image, and joins.

AP modes

A lightweight AP can run in one of several modes, set per AP on the WLC. Only Local and FlexConnect serve clients in the normal way; the rest are special-purpose.

More on the two client-serving modes because the exam focuses on them:

Local mode is the default. The AP maintains its CAPWAP tunnels, every client frame crosses the tunnel to the WLC, and the WLC drops it on the correct VLAN at the data center. The AP also spends a few hundred milliseconds at a time listening to other channels so the WLC can build its picture of the RF environment. If the CAPWAP tunnel drops, a local-mode AP stops serving clients entirely and reboots to rediscover a controller.

FlexConnect mode (formerly H-REAP) is for branch offices where the WLC lives across a WAN link. Sending every branch frame across the WAN to headquarters and back is wasteful and fails when the WAN is down. A FlexConnect AP can be configured to locally switch client traffic (drop it on the branch switch directly, which requires a trunk port for multiple VLANs) while still using the WLC for authentication and management. If the WAN fails, the AP enters standalone mode and keeps serving already authenticated clients, and can authenticate new clients against a local list. When the WLC returns, it goes back to connected mode.

WLC deployment models

Where does the WLC live? Cisco offers four deployment models, and the choice depends mainly on how many APs and clients you have.

The exact limits change with each product generation, so the exam tests the relative order rather than precise numbers: unified is biggest, then cloud, then embedded, then Mobility Express. In every model the APs are lightweight and use CAPWAP; only the location of the controller changes.

Cloud-based WLC here means Cisco’s own controller software running as a VM, which is a different thing from a cloud-managed architecture.

Cloud-managed architecture (Cisco Meraki)

Cisco Meraki APs (and switches and firewalls) are managed from a web dashboard hosted in Meraki’s cloud. There is no on-premises WLC. Each AP maintains an encrypted management connection to the cloud dashboard, from which you configure SSIDs, security, and policies for all APs in all your sites at once. The cloud handles management and monitoring and coordinates RF settings among the APs.

The critical distinction: only management traffic goes to the cloud. Client data traffic never does. A Meraki AP switches client frames directly onto the local switch, like an autonomous AP, so it typically connects to a trunk port when it serves several VLANs. If the internet connection fails, the APs keep serving clients with their last configuration; you simply cannot make changes until the connection returns.

Comparison of the three architectures: