Cisco Wireless Network Architectures

In the 802.11 service sets lesson, you learned how an AP provides a BSS for wireless clients. You also learned how we use an ESS with multiple APs to create a larger wireless network.

In this lesson, we’ll take a look at different Cisco wireless architectures we can use for enterprise networks.

Autonomous AP Architecture

We use most wireless networks as an extension of the wired network. Wireless and wired clients are on the same LAN and can communicate with each other.

An autonomous AP has all the required intelligence to serve wireless clients and to connect to the wired network. The AP can offer one or more BSSes and connect VLANs to SSIDs.

Below is a picture of what this looks like on an enterprise network:

Cisco Architecture Autonomous Ap Scaled Min

I highlighted the connections for one of the APs. Our autonomous AP is on the access layer and connected with a trunk. We have three VLANs:

  • VLAN 10: Management
  • VLAN 20: for SSID “WIFI-VLAN20”
  • VLAN 30: for SSID “WIFI-VLAN30”

We need the 802.1Q trunk to the switch; this is how the AP has access to all required VLANs. The autonomous AP also has a management IP address; we need this to SSH into the AP so we can configure things like:

  • RF parameters:
    • Channel
    • Transmit power
  • VLANs
  • SSIDs

We want to separate management and data traffic, which is why we use a separate management VLAN. Wireless users in the same VLAN can communicate directly with each other; this traffic doesn’t have to cross the wired network.

You configure each autonomous AP individually. This can be a pain; let me explain.

Let’s say you want the capability that wireless users can roam from one AP to another without losing their connection and DHCP assigned IP address. This is no problem, but it means you have to configure the same SSID and VLAN on all APs.

You also need to configure RF parameters like the channel you want to use and the transmit power. With multiple APs, you have to figure out which channels and what transmit power to use, so there is enough overlap and (almost) no interference between APs. You also need to ensure that when an AP fails, other APs can take over, so there is no coverage hole.

Requiring VLANs everywhere introduces an issue on the switched network; stretched VLANs. Take a look at the following picture:

Cisco Wireless Architecture Autonomous Ap Stretched Scaled Min

When a wireless user wants to roam from one AP to an AP that is connected to the access layer of another distribution layer, you’ll have to cross the core layer. This means your VLAN has to span the entire network.

If you want to configure a new SSID, you have to configure it on all APs. You also need to configure a new VLAN on all APs and switches.

You could make your life a bit easier and use a management platform to configure the APs. You could do this with Cisco Prime Infrastructure. There is also no central point in the network to monitor wireless traffic and do things like policing, QoS, or intrusion detection.

Another term for the autonomous AP solution is the local MAC architecture.

As you see, there are some limitations and problems with the autonomous AP setup. It’s a fine solution for a small network, but when the network grows, it doesn’t scale very well.

Split-MAC Architecture

Autonomous APs work alone; we configure them one by one. As explained, this decentralized architecture has some drawbacks:

  • If we want roaming, we need to configure VLANs and SSIDs on all APs.
  • When we want a new SSID, we also have to create a new VLAN on all switches.
  • VLANs can span the entire wired network.
  • We need to configure the RF parameters manually.
  • There is no central point in the network to do things with our wireless traffic like policing, QoS, or intrusion detection.

To overcome these problems, we move some functions from the AP to a central location, the Wireless LAN Controller (WLC):

Cisco Wireless Architecture Lightweight Ap Wlc Scaled Min

With wireless networking, we have real-time and management functions. The AP should handle real-time functions, but everything that is not delay-sensitive can do from a central location. We separate the following management and real-time functions of the AP:

  • Management functions:
    • Client authentication
    • Security management
    • Association and reassociation (roaming)
    • Quality of Service (QoS)
  • Real-time functions:
    • Transmission of 802.11 frames
    • MAC management
    • Encryption

Since these functions are not real-time, we can move them to a central point, the WLC. We take away some of the intelligence of the AP, which is why we call them lightweight APs (LAP). We move this intelligence to the WLC.Cisco Architecture Wlc Ap Realtime Management Functions

The WLC controls many APs in the network. The lightweight AP requires a WLC; it can’t function on its own. Splitting functions between the AP and WLC is what we call the split-MAC architecture.

One exception is the FlexConnect architecture. This AP connects to a WLC but can also work standalone.

When a lightweight AP boots, it uses discovery mechanisms to search and connect to a WLC. Before the AP and WLC connect, they have to authenticate each other. We do this with pre-installed X.509 certificates on the AP and WLC. This prevents someone from adding an unauthorized AP to your network.


The AP and WLC connect with a tunneling protocol, the Control And Provisioning of Wireless Access Points (CAPWAP) tunneling protocol. CAPWAP encapsulates all data between the lightweight AP and the WLC.

CAPWAP is a standard, defined in RFC 5415, 5416, 5417, and 5418. It’s based on the Lightweight Access Point Protocol (LWAPP), a legacy Cisco proprietary solution.

There are two tunnel types:

Cisco Wireless Architecture Capwap Control Data Tunnel

  • CAPWAP control messages: contain information about WLAN management. We use this to configure and manage the AP. These control messages are encrypted.
  • CAPWAP data messages: encapsulate packets to and from wireless clients who are associated with the AP. These messages are unencrypted by default

Each uses a different UDP port.

Tunneled traffic can be switched or routed. Using a tunnel means the lightweight APs and WLC don’t have to be in the same VLAN. This is useful since APs are typically on the access layer, and the WLC is in a central location (core layer or data center attached to the core).

Because of the CAPWAP tunnel, the AP and WLC are not only physically separated but also logically separated. This requires some more explanation. Take a look at the following picture:

Wireless Architecture Capwap Tunnel Vlan

The tunnel is between the IP address of the lightweight AP and the WLC. As long as they can reach each other, they can establish the tunnel. The lightweight AP connects to an access mode switchport in VLAN 11. The lightweight AP offers two SSIDs:

  • WIFI-VLAN20: Uses VLAN 20
  • WIFI-VLAN30: Uses VLAN 30

How can the lightweight AP offer an SSID that uses VLAN 20 or 30 while it’s connected to a switchport in VLAN 11? That’s what the CAPWAP tunnel is for; it tunnels VLAN 20 and 30 traffic from the lightweight AP to the WLC.

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 788 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

732 Sign Ups in the last 30 days

100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!


Forum Replies

  1. Dears ,

    I have a question about CAPWAP tunnel ,what it is exactly purpose ,what i understood from explaination is CAPWAP existed to overcome on the problem of offering user VLANs into switchport where is connected with switch

    “How can the lightweight AP offer an SSID that uses VLAN 20 or 30 while it’s connected to a switchport in VLAN 11? That’s what the CAPWAP tunnel is for; it tunnels VLAN 20 and 30 traffic from the lightweight AP to the WLC.”

    question is i think it is normal to offer an SSID that uses VLANs 20,30 to be with VLAN11 ,just to let the port whe

    ... Continue reading in our forum

  2. Hello Michael

    Yes, you could do that, and connect the access point with a trunk link to the specific VLANs that you have configured. Such a network looks like this:

    ... Continue reading in our forum

  3. Trying to clarify the APs that have to be used when using a Meraki Cloud based solution.

    You mentioned:
    “With the Cisco Meraki architecture, the management function is in the cloud and we use autonomous APs on the network.”

    Even though the Meraki APs would have a cloud based WLC, it still needs to be autonomous AP because it still needs to send data traffic via trunk links? And a lightweight AP can’t do that, correct? It’s starting to sound like a Meraki AP is in the middle of an autonomous AP and lightweight AP.

    I assume that the autonomus APs are also used i

    ... Continue reading in our forum

  4. Hello Jonah

    As you suggested, Cisco Meraki access points are a special case. They are not strictly speaking “lightweight” since they still have a level of intelligence higher than real lightweight APs. They are indeed somewhere between lightweight and autonomous APs. This is why they belong to the Cloud-Based AP Architecture category.

    Only control plane traffic is exchanged between the AP and the cloud controller. All data traffic remains on the local network. For multiple SSIDs, it is possible to tag the traffic of each SSID with the appropriate VLAN ID,

    ... Continue reading in our forum

30 more replies! Ask a question or join the discussion by visiting our Community Forum