This is the second part of the series of articles about the roles and functions of different network components (the first part is available here). In this part, we will discuss the operations of Cisco Wireless Access Points (APs) and Cisco WLAN Controllers (WLCs). The purpose of this blog post is to explain what a Cisco-based wireless network consists of and how these elements interact with each other.
IEEE 802.11 set of standards defines Layer 1 and Layer 2 operations of wireless networks. The latest standard that Cisco Access Points support at the time of writing is 802.11ax (Wi-Fi 6).
IETF’s RFC 5415 standardizes communication protocol between a WLC and an Access Point – Control And Provisioning of Wireless Access Points (CAPWAP).
Access Points (APs)
Wireless clients connect to an Access Point to communicate with each other and with the devices on the wired network that the AP is connected to. Single Access Point forms a BSS (Basic Service Set), which is identified by its MAC address.
Access Point advertises one or many wireless networks identified by an SSID (Service Set ID). A WLAN can be mapped to a VLAN on the wired side of an access point.
ESSID is the same wireless network, as identified by an SSID but advertised by multiple Access Points that are connected to the same wired network.
The current portfolio of Cisco Access Points is represented by:
- Wi-Fi 6 (802.11ax) models, such as Catalyst 9115, 9117, 9120 and 9130
- 802.11ac Wave 2 models, such as Aironet 1815, 2800, 3800 and 4800
- Outdoor and Industrial, such as Aironet 1540, 1552, 1560 and 1570
- Meraki MR45 and MR55
- Small Business 100, 300 and 500 series
Cisco website provides a selector tool that performs a side-to-side comparison of different AP and controller models. It can be accessed via this URL.
Autonomous vs Lightweight APs
Access Point’s mode of operations can be either Autonomous or Controller-based. Let’s consider the difference between management, control and data planes for Access Points operating in different modes to understand their functions.
The management plane deals with the static configuration of Access Points. APs in autonomous mode can be managed directly via Web interface or CLI. In contrast, controller-based APs don’t allow direct configuration changes and, instead, are managed by the controller, which provides a centralized interface for an administrator. The controller is not always a dedicated physical or virtual appliance, it can also be cloud-based service (Meraki) or even another access point (Mobility Express and Embedded WLC).
The control plane is responsible for dynamic access point operations, such as radio parameters management and user authentication. Autonomous APs perform all these tasks on their own. Controller-based (or Lightweight) APs shift these tasks to the controller. For example, a controller can instruct access points to change a radio channel and decrease transmit power, as it can make more informed decisions based on data received from several adjacent access points in the network.
The Data plane is responsible for moving data between wireless clients and the wired networks. An autonomous AP switches data directly to the wired network based on its SSID-to-VLAN mapping. Lightweight APs have different mode operations which define how they switch data:
- Local or Split MAC mode. In this mode, all user data traffic is tunneled to WLC
- FlexConnect – central switching mode. Data plane is similar to local mode, however, some traffic can be switched locally. When the controller is not reachable, AP operates as an autonomous AP
- FlexConnect – local switching mode. Data plane is similar to autonomous AP, which switches traffic locally to wired network based on configured SSID-to-VLAN mapping using 802.1q tagging
- SD-Access mode. In this mode, AP connects to the SD-Access Edge switch and transmits data via SD-Access fabric using VXLAN encapsulation (check this link for more information on SD-Access).
Wireless LAN Controllers (WLCs)
Managing a number of autonomous APs is getting more difficult as device number grows, as the configuration must be consistent across many devices. WLCs solve this problem by providing centralized management of the wireless network.
Current Cisco portfolio of controllers consists of:
- WLC 3504 (AireOS)
- WLC 5520 (AireOS)
- WLC 8540 (AireOS)
- Mobility Express on APs (AireOS)
- Catalyst 9800 series (IOS-XE): 9800-L, 9800-40, 9840-80, 9800-CL (virtual)
- Embedded WLC on APs and Switches (IOS-XE)
The recently released versions of WLCs can be compared using the same tool shown in the Access Points section.
Cisco Wireless LAN Controllers were traditionally running AireOS software. The Cisco controller-less solution with the WLC role performed by an 802.11ac Access Points is called Cisco Mobility Express.
Newer controllers are now IOS-XE software-based. New Catalyst 9100 Access Points can run the WLC role and this newer IOS-XE based solution is called Embedded Wireless Controller. Based on the fact that new controllers are IOS-XE based, AireOS most likely will be replaced by IOS-XE. A feature comparison of both platforms can be found here.
A controller can have multiple functions depending on types of the deployment. The next sections discuss available options.
Meraki cloud-based management
Meraki MR APs are first associated with their serial numbers with Meraki Cloud, which provides management access for the wireless LAN deployment. The AP-to-Controller communication is out-of-band and Meraki MR APs will continue to function when connectivity to Meraki Cloud is lost. During connectivity outages ability to perform configuration changes is not available.
No user data is being transferred through Meraki Cloud infrastructure. Security operations, such as authentication are performed by Meraki Access Point locally. For example, RADIUS authentication requests for WPA2 Enterprise are being sent directly from an access point.
This type of deployment is suitable for large campuses, where sufficient infrastructure exists for the controller to be deployed locally. In this scenario, controllers are actively participating in data forwarding. Access Points establish CAPWAP tunnels to the controller. One tunnel is used for the control plane and another carries encapsulated data payload.
From a wired network perspective, all wireless users traffic is originating from WLC’s LAN interface. This simplifies the configuration of switching infrastructure, as access point facing ports no longer require 802.1q trunk configuration and maintenance of allowed VLANs on that interface. Such ports can be configured as access ports. CAPWAP traffic is unicast UDP traffic between the AP and the WLC.
Figure 1 shows a simplified view of the traffic flow with the split MAC. If A sends a frame to C, AP will send it over the CAPWAP tunnel (in yellow) to WLC. AP and WLC can be in different VLANs, as CAPWAP is IP routed traffic. WLC will de-capsulate it and send it on its LAN interface connected to port 2 of the switch. The switch will learn the MAC address of A via port #2 (facing WLC).
Split-MAC configuration usually offers faster roaming when the user moves from one access point to another. There are some associated drawbacks, such as the requirement to maintain a dedicated WLC, and bandwidth scaling limits imposed by the controller’s platform and increased dependency on the WLC, as Lightweight Access Points cannot operate without an active connection to it.
The WLC and access points also support FlexConnect mode of operation. It allows Lightweight Access Point to locally switch some or all of the user traffic instead of sending it to the controller via the CAPWAP tunnel. This mode’s purpose is to decrease the amount of traffic that needs to be sent to a controller from the branch offices.
WLC appliances support 2 modes – Central Switching and Local Switching.
When WLAN is configured to use Central Switching, traffic from an AP is still tunneled to WLC, however, local-site traffic can be enabled for local switching by configuring Split Tunneling. When there is an active connection between WLC and AP, it is in Connected Mode. When the connection is lost, AP moves into a standalone mode and performs switching locally.
AP in FlexConnect Local Switching mode switches all traffic locally, even when AP can reach WLC. It is similar to the operation of autonomous APs which also switches traffic locally by mapping SSIDs to VLANs. Access Points are still controlled by WLC retaining the benefits of centralized management.
Embedded WLCs (and Mobility Express) rely on FlexConnect Local Switching operation, as there is no benefit in sending encapsulated data over the tunnel to another Access Point that performs the role of WLC.
SD-Access fabric-integrated WLC actively participates in the fabric operation via the control plane integration. For example, a WLC can update host tracking databases of the edge switch when a client registers, so this information is then distributed via a fabric LISP-based control plane.
WLC controls fabric-integrated access points perform the same functions as non-fabric WLCs, plus fabric specific operations. For example, a WLC provides an Access Point with VXLAN information (VNI) during client registration. By integrating with Cisco ISE, WLC can also provide AP with security tags (SGTs), so the policy can be enforced upstream.
In fabric mode, a WLC doesn’t participate in the data plane operation and all data is encapsulated locally by the fabric access point.
The 3rd part of the series is now available.