The Cisco Wireless LAN solution is designed to provide 802.11 wireless networking solutions for enterprises and service providers. It consists of WLCs and their associated LAPs.
Wireless LAN Controllers are responsible for system-wide wireless LAN functions, such as security policies, intrusion prevention, RF management, QoS, and mobility. They work in conjunction with Cisco APs and the WCS to support business-critical wireless applications. WLCs are responsible for system-wide WLAN functions, such as the following:
- 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
NOTE: While going into detail on all of these functions is beyond the scope of the SWITCH exam requirements, you should still be familiar with the functions listed above.
WLCs communicate with controller-based APs over any Layer 2 (Ethernet) or Layer 3 (IP) infrastructure using the LWAPP, which is an IETF draft protocol. A 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 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 a controller that runs either 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 independently of the controller.
LWAPP secures the control communication between the LAP and the controller by means of a secure key distribution, which 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.
Cisco Aironet APs that shipped before July 18, 2005, do not have a MIC, so these APs create a self-signed certificate (SSC) when they are upgraded in order to operate in Lightweight mode. Controllers are programmed to accept SSCs for the authentication of specific APs. |
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 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 the 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. It is important to remember this order of processing.
-
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 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 client’s MAC and IP addresses, security context and associations, 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 the following three types of roaming:
- Intra-controller roaming
- Inter-controller roaming
- Inter-subnet roaming
Intra-controller roaming occurs when a wireless client roams from one AP to another while both APs are joined to the same controller. This is illustrated below in Figure 9-10:
Fig. 9-10. Intra-Controller Roaming
Figure 9-10 illustrates a wireless client that has just moved from AP # 1 to AP # 2. Because both APs are under the administration of the same controller, when the wireless client is associated with AP # 2, the controller simply updates the client database with the newly associated AP. 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. This is illustrated below in Figure 9-11:
Fig. 9-11. Inter-Controller Roaming
Referencing Figure 9-11, the client roams from AP # 1, which is joined to WLC # 1, to AP # 2, which is joined to WLC # 2. Given that the WLAN interfaces of the WLCs are on the same subnet, as illustrated in the diagram, inter-controller roaming is permitted.
This is performed by the exchange of mobility and packets between the WLCs. These packets are exchanged through EtherIP packets (which are IP protocol 97). The client entry is then moved from the client database of WLC # 1 and added to the client database of WLC # 2.
Inter-subnet roaming is somewhat similar to inter-controller roaming, with some differences. With inter-subnet roaming, the WLAN 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 the IP address and the entire process is transparent. Inter-subnet roaming is illustrated below in Figure 9-12:
Fig. 9-12. Inter-Subnet Roaming
One very important aspect to remember regarding inter-subnet roaming is that it results in asynchronous routing for the client. When traffic is sent to the client, it is received by the anchor controller, which then forwards the traffic to the foreign controller in an Ethernet-over-IP (EtherIP) tunnel. When the foreign controller receives this traffic, it forwards it to the client. This is shown below in Figure 9-13:
Fig. 9-13. Sending Data to an Inter-Subnet Roaming Client
However, when the client sends traffic, it is sent to the foreign controller, which forwards it to the destination through the distribution network. This is illustrated below in Figure 9-14:
Fig. 9-14. Forwarding Data from an Inter-Subnet Roaming Client
If the client again roams to a new foreign controller, the client database entry is moved from the original foreign controller to the new foreign controller, but the original anchor controller is always maintained, as is the asynchronous routing. When the client moves back to the original controller, it becomes local again and there is no longer any asynchronous routing.
When implementing inter-subnet roaming, ensure that the WLANs on both anchor and foreign controllers have the same network access privileges. Additionally, disable source-based routing and avoid firewalls, as these may cause client network connectivity issues.
Mobility Groups
In order to support roaming, Mobility Groups must be configured. A Mobility Group is a group of WLCs in a network with the same Mobility Group name. These WLCs can dynamically share context and state of client devices, WLC loading information, and can also forward data traffic among them, which enables inter-controller wireless LAN roaming and controller redundancy. Mobility Groups must be manually (statically) defined by the administrators. The IP and the MAC addresses of the WLCs that belong to the same Mobility Group can be configured on each of the WLCs individually or via the WCS. Irrespective of the method used, keep in mind that WLCs can only be configured in one Mobility Group.
Although the configuration of Mobility Groups is beyond the scope of the SWITCH exam requirements, the following is a list of prerequisites required to configure Mobility Groups:
- All WLCs must be configured for the same LWAPP Layer 2 or Layer 3 transport mode
- All devices must have IP connectivity with each other via their management interfaces
- All WLCs must be configured with the same Mobility Group name
- All WLCs must be configured with the same virtual interface IP address
- Each WLC must be configured with the MAC and IP addresses of the other WLCs
Lightweight Access Point Operating Modes
Lightweight Access Points can operate in the following modes, which will be described in this section:
- Local mode
- Monitor mode
- REAP mode
- Rogue detector mode
- Sniffer mode
Local mode is the default mode of operation for an LAP. When an LAP is placed into local mode, it spends 60 milliseconds (ms) on channels that it does not operate on every 180 seconds. During this time, the AP performs noise floor and interference measurements, and intrusion detection (IDS).
REAP (Remote Edge Access Point) mode enables an LAP to reside across a WAN link and still be able to communicate with the WLC and provide the functionality of a regular LAP.
Monitor mode allows specified LWAPP-enabled APs to exclude themselves from handling data traffic between clients and the infrastructure. They instead act as dedicated sensors for location-based services (LBS), rogue access point detection, and IDS. When APs are in monitor mode they cannot serve clients and continuously cycle through all configured channels, listening to each channel for approximately 60 ms.
Rogue detector mode allows LAPs to monitor rogue APs. These APs should be able to see all the VLANs in the network since rogue APs can be connected to any of the VLANs in the network. The switch sends all rogue AP and client MAC address lists to the Rogue Detector (RD), which then forwards those up to the WLC in order to compare with the MACs of clients that the WLC APs have heard over the air. If MAC addresses match, then the WLC knows the rogue AP to which those clients are connected is on the wired network.
Sniffer mode allows an AP to function as a sniffer. In this mode, the AP captures and forwards all the packets on a particular channel to a remote machine that runs Airopeek. These packets contain information on timestamp, signal strength, packet size, and so on. The sniffer feature can be enabled only if you run Airopeek, which is a third-party network analyzer software that supports decoding of data packets.