1.2 Describe wireless network design principles
1.2a Wireless deployment models
Centralized
In a centralized model, the access points operate in lightweight mode rather than autonomous mode. In lightweight mode, the access point (AP) is joined to a wireless LAN controller (WLC) to function in a split-MAC architecture; where the AP handles real-time 802.11 processes and the WLC performs management functions. The AP and WLC establish a CAPWAP tunnel over the network infrastructure, where the joining process occurs and control & data traffic is carried over.
CAPWAP is the standard underlying protocol used in Cisco centralized WLAN models. It enables the configuration and management of APs as well as the encapsulation & forwarding of WLAN client traffic between the AP and WLC. CAPWAP is based on lightweight access point protocol (LWAPP) and uses DTLS for encryption.
The split-MAC concept used in centralized models is when the AP manages part of the 802.11 protocol operation, and the WLC manages the rest. The AP controls the following:
- The frame exchange handshake between the AP and supplicant.
- Transmission of beacon frames.
- Buffering & transmission of frames for supplicants in power-save mode.
- Responses to probe request frames.
- Forwarding notification of probe requests received by the WLC.
- Providing real-time signal quality information to the switch.
- Monitoring radio channels for noise and interference, and the presence of other APs.
- Encryption & decryption of 802.11 frames.
The WLC controls the following MAC functions:
- 802.11 authentication
- 802.11 association & re-association
- 802.11 frame translation and bridging
- 802.1x EAP/RADIUS processing
- Termination of 802.11 traffic on a wired interface, except in the case of FlexConnect APs
A CAPWAP tunnel encapsulates two types of traffic:
- CAPWAP control messages: data packets used to convery control, configuration, and management information between the WLC and APs.
- Wireless client data: data packets from the wireless endpoint is encapsulated from the AP to the WLC.
When encapsulated client traffic reaches the WLC, it’s typically mapped to a corresponding interface (VLAN) or interface group (VLAN pool) on the WLC. The traffic can also be dynamically mapped to a VLAN, based on WLC policies or RADIUS attributes from a AAA server.
CAPWAP only operates at layer 3, and so requires the AP and WLC to be assigned IP addresses for the tunnel to establish. The CAPWAP tunnel is created over UDP, and can perform fragmentation & reassembly of tunnel packets, allowing client traffic to use the entire 1500 byte MTU.
A lightweight discovers the WLC by using a CAPWAP discovery mechanism and then sends a join request to the WLC. After joining, the WLC manages the configuration, firmware, and data & control transactions on the AP.
FlexConnect
The FlexConnect model is designed for deployments where the WLC is reachable over a WAN link; i.e., remote offices. FlexConnect APs can join a WLC over a WAN in a central location with requiring a wireless controller in each remote office. They can also switch client data to the wired network & perform authentication locally. There are two modes of operation for FlexConnect APs:
- Connected mode: The WLC is reachable, and the AP has a CAPWAP tunnel to the wireless controller.
- Standalone mode: The WLC is unreachable, and the CAPWAP tunnel is down.
When a FlexConnect AP boots, it first searches for a controller through its discovery process. If a controller is found, it joins the controller, downloads the software image and configuration, and saves the configuration in NVRAM. Once the access point installs the software image, it needs to be converted to FlexConnect mode via the GUI or CLI.
When the access point is in connected mode, it sends client authentication requests to the controller, which performs the authentication. Depending on the configuration of the WLAN, the access point will send client data back to the controller or switch it locally. When it is in standalone, the access point authenticates clients on its own, and also switches all client data locally.
Cloud-Based
Cisco’s Meraki platform provides cloud management of the access points, in a web-based management platform hosted off-site. The web-based interface allows for easy creation of access controls and application policies. Meraki access points can also be provisioned quickly without manual configuration & provisioning.
Data from Meraki APs (configuration, statistics & monitoring, etc.) flows to the Meraki cloud over a proprietary encrypted tunnel. If the AP loses connectivity to the cloud controller, it will continue to run with the current configuration until connectivity is restored. Configuration changes on the APs, and data collection from the AP, is done via RPC initiated by the Meraki cloud; however, access points will periodically check for configuration updates on their own.
The other type of cloud-based controller is the Cisco Catalyst 9800-CL. It is based on Cisco IOS XE and integrates with Cisco Aironet access points. The 9800-CL can be deployed in both public and private cloud environments:
- It supports VMware ESXi, KVM, Hyper-V and Cisco NFVIS.
- It supports centralized, FlexConnect, mesh, and fabric deployment modes.
- It supports multiple size scales & thoughput profiles in a single deployment package:
- Small (low/high throughout): designed to support up to 1,000 access points and 10,000 clients.
- Medium (low/high throughput): designed to support up to 3,000 accesspoints and 32,000 clients.
- Large (low/high throughput): designed to support up to 6,000 access points and 64,000 clients.
- With a high throughput profile, the controller can attain up to 5Gbps on ESXi and KVM, depending on the network interface card.
The 9800-CL is available to be deployed in two public clouds: Amazon Web Services and Google Cloud Platform. Some of the aspects of operating the 9800-CL in a public cloud provider are:
- The Catalyst 9800-CL is available as an infrastructure-as-a-service solution on AWS and GCP.
- The 9800-CL should be instantiated within a virtual private cloud (VPC).
- A VPN tunnel must be established from the on-premise to AWS or GCP to enable communication between the access point and controller.
- The controller supports up to 6,000 access points and 64,000 clients.
- The controller instances can be deployed using Cloud Formation in AWS, or a guided workflow in GCP.
Embedded
For small to medium sized wireless deployments, the Cisco embedded wireless controller (EWC) can be deployed on the Catalyst 9300 & 9500 platforms. These platforms combine the switch and wireless controller in a single chassis. To use the EWC on a switch, the following requirements are needed:
- The switch platform needs to tbe Catalyst 9300, 9300L, 9500, or 9500H series.
- The IOS XE wireless subpackage must be installed.
- The access points need to be the Catalyst 9100 or Aironet 1800, 2800, 3800, 4800, 1540 or 1560 series.
A second option for a embedded controller is the wireless controller available on Catalyst and Aironet access points. One choice is the Cisco embedded wireless controller on Catalyst access points (EWC-AP). EWC-AP integrates with Cisco DNA, and can be managed through its web interface, mobile application, or standards-based programmability tools like NETCONF & YANG.
The second choice for an embedded wireless controller is Cisco Mobility Express. Cisco Mobility Express places the wireless controller functionality into Cisco Aironet access points; specifically, the Aironet 4800, 3800, 2800, 1850, 1830, 1815, 1560, & 1540 series. Mobility Express can manage up to 100 access points and 2000 clients, and can also be managed by Cisco DNA center. The WLC function can run on muliple access points, providing redundancy should the access point acting as the controller go offline.
1.2b Location Services in a WLAN Design
Within modern wireless networks, RF location tracking services are used to provide network analytics and other data about wireless clients. Cisco’s software solution for gathering wireless analytics and data is Cisco Mobile Experience (CMX). CMX is intended to enable organizations to detect, connect, and engage with end users within a wireless network:
- Detect: The wireless signal(s) from a mobile device and its characteristics are detected by access points.
- Connect: Once the device notices the available wireless network(s), the device can securely connect.
- Engage: Wireless clients can be provided with customized content on their devices.
The capabilities of CMX are delivered via three components:
- Location: Uses wireless infrastructure to determine the location of wireless devices and interference.
- CMX Connect: Provides an easy way to create custom captive portals and collect visitor information.
- CMX Analytics: Generates data about wireless device based on location & movement patterns. Two types of analytics are:
- Presence analytics: Uses signal strength & time duration of wireless devices from the access point to track real-time & historical usage patterns.
- Location analytics: Uses graph coordinates generated by the CMX Location engine to create more granular location data.
1.2c Client Density
Client density refers to the number of devices connected to the network in a specific area simultaneously. High client density can significantly impact network performance, necessitating special design considerations to cope:
- High-Density AP Deployment: Increase the number of APs in high-traffic areas to alleviate the load on each AP.
- Use of Directional Antennas: Directional antennas can help APs direct signals to specific areas, thus reducing signal interference and enhancing performance.
- MIMO (Multiple Input Multiple Output): MIMO technology increases the transmission capacity of each AP, improving network performance.
- Band Management: Use dual-band or tri-band APs (supporting 2.4GHz and 5GHz) to optimize spectrum usage.
- Quality of Service (QoS) Policies: Implement QoS policies to ensure the performance of critical applications is not affected by high traffic.