Chapter 8: Understanding Configuration Profiles, AP Groups, and Virtual APs

Chapter 8: Understanding Configuration Profiles, AP Groups, and Virtual APs
Configuration profiles and AP groups work together to provide an abstraction layer between the physical settings of the system and the conceptual goals of the network architect. This abstraction feature provides the Aruba administrator with the benefits of reusable groups of settings (called “profiles”) that can be applied in a mix-and-match fashion with extremely fine granularity.
Configuration Profiles
Configuration profiles allow different aspects of the Aruba system to be grouped into different configuration sets. Each profile is essentially a partial configuration. SSID profiles, radio profiles, and AAA profiles are just some of the available choices. Each profile includes parameters that can be adjusted to meet the needs of the design. Multiple versions of the same profile can be created and given different names. This flexibility allows the administrator to define a particular profile once and reuse it as needed, which reduces configuration errors and data entry.
The ArubaOS profile system is set up so that the configuration flow goes from high level to low level in a hierarchical manner. Unlike other hierarchical systems such as LDAP, the ArubaOS profile system does not provide arbitrary levels of depth or inheritance. The ability to copy a profile to create a new profile allows for rudimentary inheritance. Changes to the original profile are not reflected in the new profile.
To ease configuration, a set of startup and reusable wizards are available. The administrator answers basic questions about the WLAN configuration, and the wizard creates the necessary profiles to setup the WLAN.
Profile Types
The basic idea of a profile is very straightforward. With 65 different profiles available, ArubaOS 6.0 offers the administrator almost unlimited control over how their wireless network can be implemented. The main categories of profiles are shown in Figure 47. Each box represents a different profile, and certain profiles are nested within others.
Figure 47 High-level Overview of an AP Group
Administrators use these more common profiles on a regular basis:
IDS profiles: Configure IDS functions for APs. A top-level IDS profile contains other IDS default profiles. When the top level profile is selected, these things are configured automatically: detection of denial of service (DoS) and impersonation attacks, unauthorized devices on the wireless network, and intrusion signatures.
AP Groups
An AP group is a unique combination of configuration profiles. In general, all profiles can be assigned to an AP group to create a complete configuration. This flexibility in configuration allows arbitrary groupings of APs such as “All Lobby APs” or “All APs in California” with different configurations for each. Each AP group must include a minimum number of profiles, in particular, a virtual AP profile.
Each AP, AM, SM, and RAP can be a part of only one AP group at any one time. This limitation eliminates the need to merge possibly contradictory configurations and prevents multiple virtual APs with the same SSID from being enabled on the same physical AP.
Virtual AP Concept and Operation
Physical APs are often deployed around an organization, but even with two radios they cannot provide the required combinations of authentication and encryption to meet most organizational needs. If enough physical APs were added, the deployment would be too dense and cost prohibitive to deploy. The virtual access point (VAP) solves this issue.
Physical Aruba APs, unlike typical home APs, are often configured to appear as more than one physical AP. This configuration provides the necessary authentication and encryption combinations without collocating excessive amounts of APs in the same physical area.
The VAPs share the same channel and power settings on the radio, but each appears as a separate AP with its own SSID (ESSID) and MAC address (BSSID). Figure 48 shows an AP with three virtual APs broadcasting three different SSIDs.
arun_055 SSIDs.png
Figure 48 A typical set of virtual APs on one physical AP
Aruba supports up to eight BSSIDs per radio on the AP, with a maximum of 16 VAPs per physical AP. The maximum total supported BSSIDs across the WLAN are a function of the mobility controller model. For more on these limitations, see the mobility controller matrix and AP matrix on the Aruba networks public site at http://www.arubanetworks.com.
Aruba does not recommend running an AP with the maximum number of VAPs available. Each VAP acts like a real AP and is required to beacon like any other AP. This beaconing consumes valuable airtime that would otherwise be used by clients to transmit data on the channel. Aruba recommends employing user roles and firewall policy to minimize the number of SSIDs in use. Instead of multiple SSIDs, deploy a new SSID only when a new encryption or authentication type is required.
The BSSIDs assigned to the SSIDs on a physical AP are generated from the MAC address of the physical AP. All the BSSIDs are generated by an algorithm. The BSSID assigned to each SSID is random. Whenever an AP reboots, the BSSID to SSID mapping may change. In certain situations, an SSID may be temporarily disabled for maintenance. When this SSID is enabled again, the BSSID assigned to it might not be the same as before.
SSIDs, Encryption, and Authentication
As mentioned previously, a new SSID is required each time a new encryption or authentication type is required, which drives the creation of an additional VAP. This situation has the following limitations:
Two VAPs in the same AP group cannot share the same SSID. Clients could easily be confused and it does not make sense to have the same SSID broadcast multiple times from the same AP on the same band.
Radio Settings
A number of radio settings affect how the WLAN functions. Some of the key functions are described here:
ARM: All the ARM settings are available within the AP group, which allows administrators to tune the network to match the environment, from typical campus settings to warehouses.
Data rates: In some instances, it is useful to eliminate lower data rates to force clients to find a more attractive AP, such as in a dense stadium deployment. Detailed discussions of this topic can be found in the High Density VRD, available at http://www.arubanetworks.com/vrd.
Country codes: Certain features of the 802.11n standard (and even 802.11n itself) are not allowed to be used in all countries. In addition, channel and power limits vary by location. The country code on the controller allows Aruba to control what features of the specification, power, and channel are usable in each location. As the regulations change and more features are allowed, the software can be updated to enable these features.
WMM
Wi-Fi Multimedia (WMM) is a certification program that was created by the Wi-Fi Alliance that covers QoS over Wi-Fi networks. WMM prioritizes traffic into one of four queues, and traffic receives different treatment in the network based on its traffic class. The different treatment includes a shortened wait time between packets and wired-side tagging of packets using DSCP and 802.1p marks. Aruba allows users to define which traffic fits in to each queue. Also, DSCP and 802.1p marks can be adjusted appropriately to match the network.
LMS and Backup LMS
The Aruba system has a concept of a local management switch (LMS) and a backup LMS. These terms are older terms that survive in the configuration; an LMS is a local mobility controller. In a typical deployment, the AP contacts the master mobility controller and is directed to the mobility controller that handles the AP connection and traffic via the LMS parameter. This controller is typically a local controller, but it can also be the master in smaller networks. If the LMS becomes unreachable and a backup LMS is specified, the AP attempts to reconnect to that backup mobility controller. This function provides Layer 3 and site redundancy when this level of redundancy is required.
Designing VAPs to Meet Organizational Needs
Some planning is needed to use the profile system effectively. Unlike most planning decisions in network designs, profile planning is not based on performance and scalability. Profile planning is based on creating a functional and flexible network design that can be logically understood. Ideally, this planning is part of the network planning.
Though it is possible simply to place all of the equipment in default profiles and change the parameters to suit the needs of the organization, the full power and flexibility of the system will not be available. To take full advantage of the system, the network administrator must consider the physical layout of the equipment, the technical management requirements, and the business practices and regulatory requirements that are specific to the organization.
The Aruba controllers that run earlier versions of ArubaOS have a predefined AP group named default. When an AP boots up and finds a controller, it is automatically placed in the default AP group. This AP group has a default VAP and SSID that have open authentication by default. The AP now broadcasts the default SSID to which clients can connect. Aruba recommends that network administrators change the following defaults:
Aruba recommends that network administrators change the default AP group for new APs to AM mode and create a new AP group with the specific SSIDs and related configuration to be used for the organization. When the default is set to AM mode, anyone who plugs an unauthorized Aruba AP into the network simply adds to the monitoring capacity and does not create a potential security vulnerability.
The default SSID profile should not be used in an Aruba deployment. Network administrators are encouraged to make the default profile an AM profile to help protect their network from “gray market” APs that users may attempt to connect to the WLAN.
In ArubaOS 6.1, the default SSID has been removed from the default AP group. So an AP that is automatically placed in the default AP group by an Aruba controller running ArubaOS 6.1 will not broadcast any SSID.