The Cisco Wireless LAN solution is designed to provide IEEE 802.11 wireless networking solutions for both enterprises and service providers. It consists of Cisco Wireless LAN Controllers (WLCs) and their associated Lightweight Access Points (LAPs).
WLCs work in conjunction with Cisco Access Points as well as the Cisco Wireless Control System (WCS) to support business-critical wireless applications. WLCs are responsible for system wide wireless LAN functions, such as:
- Integrated Intrusion Prevention System (IPS)
- Zero-Touch Deployment of Lightweight Access Points (LAPs)
- Real-time Radio Frequency (RF) management
- Wireless LAN Redundancy
- Dynamic Channel Assignment for each LAP
- Dynamic Client Load Balancing across LAPs
- Dynamic LAP Transmit Power Optimization
- Wireless LAN Security Management
WLCs communicate with Controller-based Access Points over any Layer 2 (Ethernet) or Layer 3 (IP) infrastructure using the Lightweight Access Point Protocol (LWAPP). LWAPP is an IETF draft protocol. A Lightweight Access Point (LAP) discovers a controller with the use of LWAPP discovery mechanisms. The LAP sends an LWAPP join request to the WLC and the controller sends the LAP an LWAPP join response, which allows the AP to join the controller.
When using LWAPP, although the LAP is under the control of the centralized WLC, the actual processing of data and management protocols and Access Point capabilities is divided between the LAP and the centralized WLC (the split-MAC architecture).
NOTE: In controller software release 5.2 or later, Cisco LAPs use the IETF standard Control and Provisioning of Wireless Access Points protocol (CAPWAP) in order to communicate between the controller and other LAPs on the network. Controller software releases prior to 5.2 use the Lightweight Access Point Protocol (LWAPP) for these communications.
CAPWAP, which is based on LWAPP, is a standard, interoperable protocol that enables a controller to manage a collection of wireless APs. LAPs can discover and join a CAPWAP controller. The one exception is for Layer 2 deployments, which are not supported by CAPWAP. Additionally, CAPWAP and LWAPP controllers may be deployed in the same network. The CAPWAP-enabled software allows APs to join either a controller that runs CAPWAP or LWAPP.
When the LAP joins to the controller, it downloads the controller software if the revisions on the LAP and controller do not match. Following that, the LAP is completely under the control of the controller and is unable to function independent of the controller.
LWAPP secures the control communication between the LAP and the controller by means of a secure key distribution. The secure key distribution requires already provisioned X.509 digital certificates on both the LAP and the controller. Factory-installed certificates are referenced with the term “MIC”, which is an acronym for Manufacturing Installed Certificate.
The LWAPP Discovery Process
Despite the split-MAC architecture, it is important to remember that Lightweight Access Points (LAPs) cannot act independently of the WLC. The WLC manages the LAP configurations and firmware. The LAPs are zero-touch deployed; meaning that there is no individual configuration of LAPs is required when they are deployed into the WLAN.
In order for the WLC to manage the LAP, the LAP should discover the controller and register with the WLC. After the LAP has registered to the WLC, LWAPP messages are exchanged and the AP initiates a firmware download from the WLC if there is a version mismatch between the AP and WLC. This allows the LAP to sync with the WLC.
Following the sync, the WLC provisions the LAP with the configurations that are specific to the WLANs so that the LAP can accept client associations. These WLAN-specific configurations include the Service set identifier (SSID), any additional required security parameters, and 802.11 parameters, such as the data rate, radio channels to use and the power levels. The following sequence of events must occur in order for an LAP to register to a WLC:
- The LAPs issue a DHCP Discovery Request to get an IP address. This only happens if the LAP has not been configured with a static IP address
- The LAP sends LWAPP discovery request messages to the WLCs. If Layer 2 LWAPP mode is supported on the LAP, the LAP broadcasts an LWAPP discovery message in a Layer 2 LWAPP frame. However, if the LAP or the WLC does not support Layer 2 LWAPP mode, the LAP attempts a Layer 3 LWAPP WLC discovery. The LAPs use the Layer 3 discovery algorithm only if the Layer 2 discovery method is not supported or if the Layer 2 discovery method fails. The LWAPP Layer 3 WLC discovery algorithm repeats until at least one WLC is found and joined
- Any available WLC that receives the LWAPP DHCP Discovery Request responds with an LWAPP Discovery Response
- If the LAP receives more than one LWAPP Discovery Response, it selects the WLC to join, which is typically the first WLC to respond to the LAP
- The LAP then sends an LWAPP Join Request to the WLC and the WLC validates the LAP and then sends an LWAPP Join Response to the LAP
- The LAP validates the WLC, which then completes the Discovery and Join process. The LWAPP Join process includes mutual authentication and encryption key derivation, which is used to secure both the join process and LWAPP control messages between the LAP and WLC
- The LAP registers with the WLC and can begin accepting client associations
Wireless LAN Roaming
One of the most significant advantages of WLANs over wired LANs is roaming, or mobility. Roaming is a wireless LAN client’s ability to maintain its association seamlessly from one AP to another securely and with as little latency as possible.
When a wireless client associates and authenticates to an AP, the APs controller places an entry for that client in its client database. This entry includes the clients MAC and IP addresses, security context and associations, Quality of Service (QoS) contexts, the WLAN, and the associated AP. The controller uses this information to forward frames and manage traffic to and from the wireless client. The Cisco WLAN supports three types of roaming, which are:
- Intra-controller Roaming (Same Subnet)
- Inter-controller Roaming (Same Subnet)
- Inter-Subnet (Layer 3) Roaming
Intra-controller roaming occurs when a wireless client roaming from one AP to another when both APs are joined to the same controller. In such cases, the controller simply updates the client database with the newly associated access point. If necessary, new security context and associations are established as well.
Inter-controller roaming occurs when the client roams from an AP joined to one controller to an AP joined to a different controller. When the client associates to an AP joined to a new controller, the new controller exchanges mobility messages with the original controller, and the client database entry is moved to the new controller. New security context and associations are established if necessary, and the client database entry is updated for the new AP. This process is transparent or invisible to the user and is facilitated by the exchange of mobility and packets between the WLCs. These packets are exchanged through EtherIP packets (IP protocol 97).
Inter-subnet roaming is somewhat similar to inter-controller roaming, with some differences. With inter-subnet roaming, the wireless LAN interfaces of the WLCs are on different subnets. In addition to this, inter-subnet roaming does not move the client database entry to the new controller. Instead, the original controller marks the client with an anchor entry in its local database, and this is then copied to the new controller client database and marked as a foreign entry. The client keeps their IP address and the entire process is transparent to them.