Logical Infrastructure Requirements
The path in which traffic flows through a network appears differently depending on your point of view. For example, from a network technician’s point of view, a packet travels through the network in a hop-by-hop path across each physically connected device. However, from a wireless end user’s perspective, if traffic is tunneled in an overlay, the user may only see one hop between an access point and the controller, when in reality numerous physical hops were encountered along the path of the underlying network. This is the difference between the physical and logical network.
Traffic also flows differently depending on the deployment model chosen: autonomous access points act as direct links between the wireless and the wired sides of the network, whereas centrally controlled access points in Local mode must forward all wireless client traffic to the controller over an encapsulated CAPWAP tunnel. In FlexConnect mode, some WLANs may be locally switched at the AP, while others may be centrally switched on the controller.
The following section will explore some of the logical infrastructure characteristics of a wireless network, including flow of the CAPWAP channels, logical connections to services supporting the wireless infrastructure such as AAA and DHCP servers, and finally the licensing options that are available to support the wireless deployment.
CAPWAP Flow
CAPWAP is a logical network connection between access points and a wireless LAN controller. CAPWAP is used to manage the behavior of the APs as well as tunnel encapsulated 802.11 traffic back to the controller.
CAPWAP sessions are established between the AP’s logical IP address (gained through DHCP) and the controller’s management interface. (In older versions of AireOS, the CAPWAP session terminated on the ap-manager interface; however, this has been changed to the management interface in more recent versions of AireOS.)
Whether in Local or FlexConnect mode, CAPWAP sessions between the controller and AP are used to manage the behavior of the AP. When in Local mode, CAPWAP is additionally used to encapsulate and tunnel all wireless client traffic so that it can be centrally processed by the controller. CAPWAP sessions use UDP for both the control and data channels, as follows:
CAPWAP Control Channel: Uses UDP port 5246
CAPWAP Data Channel: Uses UDP port 5247 and encapsulates (tunnels) the client’s 802.11 frames
Figure 4-9 illustrates the different CAPWAP channels between an AP and a controller.
)
Figure 4-9 CAPWAP Control and Data Plane Channels
If there is a firewall or router with access control lists (ACLs) along the logical path between the AP and the controller, it is important to ensure that rules are in place to allow both the CAPWAP control and data channel ports through the firewall so that the AP and controller are able to communicate correctly. A complete list of recommended firewall rules can be found here:
As the number of APs grows, so does the number of CAPWAP tunnels terminating on the controller. Figure 4-10 illustrates the logical connection of multiple CAPWAP sessions over the physical infrastructure.
)
Figure 4-10 CAPWAP Sessions Between the APs and the Controller
Considering that all APs in Local mode use CAPWAP to tunnel 802.11 client traffic back to the controller, an important design criterion related to traffic load must be considered. With 802.11ac Wave 2, the maximum theoretical throughput of a single AP is ~1.3Gbps. 802.11ax (Wi-Fi 6) promises even greater speeds, with the theoretical throughput expected to be in excess of 10Gbps from a single AP (based on multiple streams). Considering the CAPWAP data channel will need to support increasing levels of data throughput (not to mention framing and packet overhead), the demands of the logical infrastructure have a direct correlation to capabilities of the underlying physical infrastructure. In this vein, careful analysis must be taken at various places in the network to determine if the performance demands of the wireless network can be met. This includes the following design aspects:
The physical connection between the AP and the access switch (evaluate if mGig is required)
An estimation of oversubscription of the uplink of the access switch to the network
Backbone capacity of the core network
WAN connection speeds if the controllers are centralized and APs are in Local mode
Network access speeds to the controller
Performance capabilities of the controller
From a design perspective, the theoretical maximum bandwidth consumption of an AP is usually never attained. However, if enough APs are simultaneously generating a high volume of traffic, a controller can quickly run out of resources. Take the example of a controller that is licensed for 500 APs. If these were all Wi-Fi 6 APs passing an excessively high volume of traffic, the aggregate bandwidth capacity of the physical connection to the controller could be quickly exhausted, meaning more controllers wither fewer APs may be necessary.
Performance issues at the controller may manifest in two possible ways: (1) the underlying network’s ability to aggregate all CAPWAP data traffic and forward it without oversubscription of the physical links connected to the controller, and (2) the controller’s own performance limitations in being able to process the volume of data it is receiving.
If either of these two cases emerges, certain design changes can be considered. One change is decentralizing and splitting the function of the controllers such that less data is being managed by a single controller. Another option is to simply reduce the number of APs that each controller manages. If decentralizing the controllers is preferred, the roaming path must also be considered. While roaming between APs connected to the same controller is simple and should be seamless, if clients roam to an AP connected to a different controller, the roaming path will involve intercontroller communication and greater network complexity.
Another area where oversubscription may be an issue is on the access switch where the APs are physically connected. Take the example of an access switch with several dozen APs connected with mGig, all running Wi-Fi 6. If the clients associated to these APs are generating large amounts of aggregate data, the throughput demands could quickly exhaust even a 10Gbps uplink from the access switch. Thus, it is imperative to assess not only how many APs are being deployed (and how many of each type), but also careful calculation must be made to determine if the uplink capacity of the access switches can accommodate expected traffic demands, including how much oversubscription is acceptable. If it is found that the oversubscription rate is excessive, then either multiple uplinks will be needed (which requires port channeling) or a fewer number of APs should be deployed on each access switch.
AAA and DHCP Services Logical Path
Another area where the logical path requires careful consideration is the path between the controller and the key services, such as the AAA and DHCP servers. Services such as AAA (ISE), DHCP, DNS, MSE/CMX, DNA Spaces, and many more may be placed at locations throughout the network that have firewalls protecting them. Understanding the logical path between these services will often require opening of firewall rules for the service to interface with the controller.
As with CAPWAP, the controller’s management interface is used to communicate with AAA servers, as well as a host of other services, including MSE/CMX, directory servers, other controllers, and more.
For DHCP, controllers proxy communication to the DHCP sever on behalf of clients using the controller’s IP address in the VLAN associated to the WLAN of those clients.
Table 4-4 summarize the ports that must be open to allow the controller to communicate with key services.
Table 4-4 Summary of AAA and DHCP Services and Ports Used for the Wireless Infrastructure
Service |
Port |
|---|---|
RADIUS Authentication |
UDP port 1812 (some older versions use UDP port 1645) |
RADIUS Authorization |
UDP port 1813 (some older versions use UDP port 1646) |
DHCP Server |
UDP port 67 |
DHCP Client |
UDP port 68 |
Licensing Overview
In addition to purchasing the controller itself, Cisco wireless deployments require licenses to activate the use of the access points. The following section provides a summary of how Cisco wireless controllers and APs are licensed.
Cisco AireOS wireless controllers support two types of licensing models: Right to Use (RTU) licensing and Smart Licensing.
Right to Use Licensing
Right to Use (RTU) licensing is an honor-based licensing mechanism that allows AP licenses to be enabled on AireOS controllers (such as the 5520 and 8500 series controllers) with end user license agreement (EULA) acceptance. The RTU license scheme simplifies the addition, deletion, and transfer of AP licenses and does not require specialized license keys or product activation key (PAK) licenses.
With RTU licensing, there are three types of licenses:
Permanent licenses: The AP count is programmed into nonvolatile memory at the time of manufacturing. These licenses are not transferable from one controller to another.
Adder access point count licenses: These are additional licenses that can be activated through the acceptance of the agreement. These licenses are also transferable between controllers and types of AireOS controllers.
Evaluation licenses: These are used for demo and/or trial periods and are valid for 90 days, and they default to the full capacity of the controller. The evaluation license activation is performed through the AireOS command-line interface (CLI).
Smart Licensing
In addition to the RTU licensing model, AireOS controllers support Smart Licensing. Smart Licensing is a cloud-based flexible licensing model that simplifies the way licenses are managed across an organization rather than on a per-controller basis. The intent of Smart Licensing is to make it easier to manage and deploy Cisco software licenses from a central repository without having to track how licenses are used on individual products.
Instead of using product activation keys (PAKs) or RTU licensing, Smart Licenses establish a central pool of AP software licenses in a customer-defined Smart Account that can be used across the enterprise and across all controllers or APs. Smart Licensed products self-register upon configuration and activation with a single token, removing the need to register products individually with separate PAKs or to accept a license agreement. Thus, instead of licensing each individual controller for the number of APs that the administrator anticipates it to manage, the pool of licenses can be shared across all controllers in the enterprise and be used as needed. This approach has a distinct advantage over legacy licensing models by greatly simplifying and optimizing the use of licenses.
In the RTU model, one controller may be licensed for far more APs than it is currently managing, whereas another controller may not have enough licenses for what it needs. Smart Licensing eliminates the overhead and waste by simply putting all AP licenses in a central pool that can be managed and budgeted for as the need arises. As new APs are added or moved across the organization, the administrator no longer needs to determine the current license count on a per-controller basis—only the Smart Licensing pool of AP licenses needs to be monitored and maintained. This not only provides better utilization of licenses but also it makes it easier to procure and deploy licenses as the organization grows.
To use Smart Licensing, the following steps must be followed:
Step 1. Create a Smart Account:
Create a Smart Account at the following link: https://software.cisco.com/software/company/smartaccounts/home#accountcreation-account.
Go to Cisco Software Central at software.cisco.com.
An editable profile appears.
An email is automatically sent to the customer Smart Account administrator.
Step 2. Register the Cisco controller using the Smart Account.
For existing customers, deposit existing licenses, if any, into the Smart Account.
For a new purchase, purchase a Cisco DNA license for access points connecting to the Cisco Catalyst controller.
Step 3. Configure the license level on the controller, as desired.