A little bit of training, some researching, and a lot of time on the GUI is what I found to be the recipe in getting comfortable with Aruba Wireless Controllers. Even though I spent more time configuring the controllers via GUI, knowing the syntaxes I now find it much simpler to do it via the CLI. I do find the controller GUI much more useful in troubleshooting and verifying the wireless client connectivity. In this blog, I will share some knowledge and insights that I have gained while deploying Aruba’s Wireless Controllers for one of our customers.
Aruba offers wireless controllers in the 7000 series and 7200 series models. The 7000 series controllers scale for small to large branch offices from 16 to 64 maximum AP capacity with an option of up to 24 switchports for unified wired and wireless access. The 7200 series controllers are suitable for campus networks and support from 256 APs to 2,048 maximum AP capacity.
The controllers can be deployed as Master or Local. Aruba suggest deploying the 7000 series controllers as Local, while the 7200 series are typically deployed as Master controllers. In a Master-Local deployment, Master holds responsibility of all policy configurations. This would include services such as WIPS, Initial AP configurations, user roles and authentication related configurations, etc. The Local controller terminates AP tunnels, processes and forwards user traffic (including authentication), manages ARM (Adaptive Radio Management), Mobility features and QoS.
Aruba also offers a Mobility Master Appliance which provides additional features which are not available in the other controller models. It provides controller clustering capability that allow better user experience via features like Hitless Failover, Automatic User Load Balancing, Automatic AP Load Balancing, and Seamless Roaming across the cluster. This type of deployment could perhaps be considered for sensitive environments where high wireless performance and reliability is a requirement for critical services.
Note: ArubaOS 8.X is required with Mobility Master Appliance. APs cannot terminate on any Master or Mobility Master controllers with this code, they can only terminate on controllers deployed in Local mode. ArubaOS 6.X allows AP termination on either Master or Local controllers.
Master controller(s) can be configured with the Centralized Licensing feature. This allows the creation of a shared pool of AP Licenses that can be used by all controllers in the network. When an AP joins a Local controller, it consumes an AP License along with a PEF-NG (Aruba’s Policy Enforcement Firewall) and an RFProtect License from the pool.
While Centralized Licensing allows flexibility, it is important to note that the Maximum AP Capacity of some of the smaller controllers can be a “Gotcha”, if not designed carefully. Suppose you have deployed a 7205 model controller as the Master and a 7030 controller as the Local in a Master-Local HA Active-Active deployment, with a total of 100 AP licenses and centralized licensing feature is enabled. [DD1] [NP2] If the APs are load balanced (50-50 on each controller) and master controller fails, only 14 APs would failover and 36 of them would be down. This is due to the AP capacity of 7030 model controllers only allowing 64 APs to join it.
To enable redundancy, any combination of HA Deployment Models can be used…
- Master / Standby Master with HA Active-Active Local Controllers — Full redundancy
- Master with HA Active-Standby Locals — N+1 Redundancy with Over-subscription
- Master-Local HA Active-Active or Standby-Active — Master Active or acting as backup LMS
- Independent Masters HA Active-Active — No local controllers, each master acting as backup for the other
As long as the pool of AP licenses are not exceeded, APs have failover capability to the backup LMS IP, which can be another Local or Master based on deployment. During failover to the backup LMS, APs would normally reboot causing minutes of outage, unless Aruba’s AP Fast Failover feature is enabled. This feature allows APs to form standby tunnels to the backup LMS for instant failover and minimize downtime.
Aruba wireless controller configurations take a hierarchal approach, where multiple configuration profiles are built separately and are attached to higher-level profiles. Best practice is to configure the lowest-level settings and profiles first, then build up. Reviewing these controller configurations may be confusing for a lot of us without fully understanding the configurational hierarchy.
Following is an output of the CLI command “show profile-hierarchy” on a 7205 controller, it shows how profiles relate to each other and provide some clarity.
ap-group wlan virtual-ap aaa profile aaa authentication mac aaa server-group aaa authentication-server radius aaa radius modifier aaa authentication dot1x aaa xml-api server aaa rfc-3576-server wlan dot11k-profile wlan handover-trigger-profile wlan rrm-ie-profile wlan bcn-rpt-req-profile wlan tsm-req-profile wlan hotspot hs2-profile wlan hotspot advertisement-profile wlan hotspot anqp-venue-name-profile wlan hotspot anqp-nwk-auth-profile wlan hotspot anqp-roam-cons-profile wlan hotspot anqp-nai-realm-profile wlan hotspot anqp-3gpp-nwk-profile wlan hotspot anqp-ip-addr-avail-profile wlan hotspot h2qp-wan-metrics-profile wlan hotspot h2qp-operator-friendly-name-profile wlan hotspot h2qp-conn-capability-profile wlan hotspot h2qp-op-cl-profile wlan hotspot h2qp-osu-prov-list-profile wlan hotspot anqp-domain-name-profile wlan ssid-profile wlan edca-parameters-profile station wlan edca-parameters-profile ap wlan ht-ssid-profile wlan dot11r-profile wlan wmm-traffic-management-profile wlan anyspot-profile rf dot11a-radio-profile rf spectrum-profile rf arm-profile rf ht-radio-profile rf am-scan-profile rf dot11g-radio-profile rf spectrum-profile rf arm-profile rf ht-radio-profile rf am-scan-profile ap wired-port-profile ap wired-ap-profile ap enet-link-profile ap lldp profile ap lldp med-network-policy-profile aaa profile aaa authentication mac aaa server-group aaa authentication-server radius aaa radius modifier aaa authentication dot1x aaa xml-api server aaa rfc-3576-server ap system-profile wlan voip-cac-profile wlan traffic-management-profile wlan virtual-ap aaa profile aaa authentication mac aaa server-group aaa authentication-server radius aaa radius modifier aaa authentication dot1x aaa xml-api server aaa rfc-3576-server wlan dot11k-profile wlan handover-trigger-profile wlan rrm-ie-profile wlan bcn-rpt-req-profile wlan tsm-req-profile wlan hotspot hs2-profile wlan hotspot advertisement-profile wlan hotspot anqp-venue-name-profile wlan hotspot anqp-nwk-auth-profile wlan hotspot anqp-roam-cons-profile wlan hotspot anqp-nai-realm-profile wlan hotspot anqp-3gpp-nwk-profile wlan hotspot anqp-ip-addr-avail-profile wlan hotspot h2qp-wan-metrics-profile wlan hotspot h2qp-operator-friendly-name-profile wlan hotspot h2qp-conn-capability-profile wlan hotspot h2qp-op-cl-profile wlan hotspot h2qp-osu-prov-list-profile wlan hotspot anqp-domain-name-profile wlan ssid-profile wlan edca-parameters-profile station wlan edca-parameters-profile ap wlan ht-ssid-profile wlan dot11r-profile wlan wmm-traffic-management-profile wlan anyspot-profile ap regulatory-domain-profile rf optimization-profile rf event-thresholds-profile ids profile ids general-profile ids signature-matching-profile ids signature-profile ids dos-profile ids rate-thresholds-profile ids impersonation-profile ids unauthorized-device-profile ap mesh-radio-profile ap mesh-ht-ssid-profile ap mesh-cluster-profile rf arm-rf-domain-profile ap provisioning-profile ap authorization-profile
Fortunately, you only need to configure a few of these for a successful deployment. Many of the profiles and parameters do not require tweaking in most environments. Here is a review of some of the important configurations and profiles that were recently deployed at a customer site.
The chart above walks through the configuration flow from low-level (top) to high-level (bottom) profiles.
Note: the example configurations shown are only partial configurations to provide a visual and are valid for ArubaOS 6.x code command line.
Starting from the bottom of the chart…
AP-Group combines it all. Each AP must be assigned to an AP-Group at the time of deployment. An AP-Group essentially defines SSIDs the AP will know of and advertise, authentication used, VLAN assignation, etc. You can use a single AP-Group for the entire network or break it down per site or region. Unless you are advertising different SSIDs for different sets of APs (per site or region), it is simpler to use a single AP-Group.
A Virtual-AP Profile is created per SSID and is assigned to the AP-Group. Each Virtual-AP profile is assigned an SSID Profile which defines the SSID and a AAA Profile which defines all authentication parameters corresponding to that SSID. A VLAN is also configured under the Virtual-AP profile and is assigned to all users by default, unless a specific VLAN is assigned to the User Roleto which a user is assigned, which takes precedence. Attributes are then configured under the AAA profile. AAA authentication parameters are defined within the AAA server/group, dot1x, captive portal etc. User Roles are also configured under AAA profiles to define the pre- or post-authentication roles for users.
User Role defines the access a user is permitted based on the configured Firewall Policiesfor each role. Firewall Policies are essentially ACLs (standard, extended, service based, etc.). As users attempt to connect to any SSID, they are assigned with an initial role. These initial roles define what type of access the user will have prior to authenticating (i.e. only http / https access to the captive portal for guests to authenticate). Once authenticated successfully, a user will get assigned a post-authentication role that provides network access defined by the administrator (i.e only http / https access to the internet, blocking all communications to RFC 1918 address space). User Role can also be derived as a Radius attribute from the AAA server with successful authentication. A VLAN can be assigned to the User Role, to either put them in an initial VLAN with restrictive access or to assign them with a special access VLAN (i.e. Network Admin Access).
Overall, Aruba Wireless Controllers are fairly simple to configure and seem to provide great flexibility in deploying Wireless solutions for your needs. More of my experience this year was with the ArubaOS 6.x code which vastly defers from the new 8.x train, new features, new look, etc. Next up for our customer is transitioning from 6.x to 8.x code with a new pair of Mobility Master controllers, perhaps also the topic for my next blog.
Mobility Boot Camp (Training):
ArubaOS 6.4.4.x User Guide: