AP Architectures
APs can be networked together in a variety of architectures. The size and scalability of the network determine which architecture is most suited for a given implementation.
Autonomous AP Architecture
An autonomous AP is a self-contained device with both wired and wireless hardware so that it can bridge to the wired VLAN infrastructure wireless clients that belong to SSIDs, as shown in Figure 22-7. Each autonomous AP must be configured with a management IP address so that it can be remotely accessed using Telnet, SSH, or a web interface. Each AP must be individually managed and maintained unless you use a management platform such as Cisco DNA Center.
)
Figure 22-7 Autonomous APs
Cloud-Based AP Architecture
Cloud-based AP management is an alternative to purchasing a management platform. The AP management function is pushed into the Internet cloud. For example, Cisco Meraki is a cloud-based AP management service that allows you to automatically deploy Cisco Meraki APs. These APs can then be managed from the Meraki cloud web interface (dashboard). In Figure 22-8, the same APs shown in Figure 22-7 are now managed in the cloud.
)
Figure 22-8 Cisco Meraki Cloud-Based AP Management
Notice that there are two distinct paths for data traffic and for management traffic, corresponding to the following two functions:
A control plane: Traffic used to control, configure, manage, and monitor the AP itself
A data plane: End-user traffic passing through the AP
Lightweight AP Architectures
Wireless LAN controllers (WLCs) use Lightweight Access Point Protocol (LWAPP) to communicate with lightweight APs (LAPs), as shown in Figure 22-9. LAPs are useful in situations where many APs are required in the network. They are “lightweight” because they only perform the 802.11 wireless operation for wireless clients. Each LAP is automatically configured and managed by the WLC.
)
Figure 22-9 Controller-Based AP Architecture
Notice in Figure 22-9 that the WLC has four ports connected to the switching infrastructure. These four ports are configured as a link aggregation group (LAG) so they can be bundled together. Much like EtherChannel, LAG provides redundancy and load balancing.
CAPWAP Operation
The division of labor between the WLC and LAPs is known as split-MAC architecture. The LAP must interact with wireless clients on some low level, known as the Media Access Control (MAC) layer. These functions must stay with the LAP hardware, closest to the clients. The management functions are not integral to handling frames but are things that should be centrally administered. Therefore, those functions can be moved to a centrally located platform away from the AP. Table 22-2 summarizes MAC functions of the LAP and WLC.
Table 22-2 Split-MAC Functions of the AP and WLC
AP MAC Functions |
WLC MAC Functions |
Beacons and probe responses |
Authentication |
Packet acknowledgments and retransmissions |
Association and re-association of roaming clients |
Frame queueing and packet prioritization |
Frame translation to other protocols |
MAC layer data encryption and decryption |
Termination of 802.11 traffic on a wired interface |
LWAPP has been replaced with the Control and Provisioning of Wireless Access Points (CAPWAP) tunneling protocol to implement these split-MAC functions. CAPWAP uses two tunnels—one for control and one for data—as shown in Figure 22-10 and described in the list that follows:
)
Figure 22-10 CAPWAP Control and Data Tunnels
CAPWAP control message tunnel: Carries exchanges that are used to configure the LAP and manage its operation. The control messages are authenticated and encrypted, so the LAP is securely controlled by only the appropriate WLC and then transported over the control tunnel using UDP port 5246.
CAPWAP data tunnel: Used for packets traveling to and from wireless clients that are associated with the AP. Data packets are transported over the data tunnel using UDP port 5247 but are not encrypted by default. When data encryption is enabled for a LAP, packets are protected with Datagram Transport Layer Security (DTLS).