Aruba Wireless Controller CLI Configuration Made Easy


I’ve been working extensively with Aruba Networks Mobility Controllers at my current job and I’ve put together some quick documentation to go over the basics of the CLI configuration.

While some parts of the Aruba configuration are easily managed from the GUI, I usually find it much easier to work with the Cisco-like CLI.


Parts of the Configuration

The Top of the Hierarchy – AP Groups

AP groups are the configuration that is ultimately assigned to APs. You can see this as the “root” of the configuration, as this section ultimately references many other sections of the configuration.

AP Groups define which SSIDs are broadcast, which channels are used, traffic shaping, HA information, and more. All subsequent configuration is referenced from AP Groups.

Here we see two virtual-aps (SSID Configuration) to broadcast, the radio-profiles (Radio Rates),  ap-system-profiles (HA info), traffic-mgmt-profiles (QOS), and the regulatory-domain-profile (which wireless channels can be used).

ap-group "test_ap_group"                                        
virtual-ap "vap_psktest"
virtual-ap "vap_authtest"
dot11a-radio-profile "test_rf_radio-profile-dot11a"              
dot11g-radio-profile "test_rf_radio-profile-dot11g"
ap-system-profile "test_prof"                                  
dot11a-traffic-mgmt-profile "TrafficShapingFair"                    
dot11g-traffic-mgmt-profile "TrafficShapingFair"
regulatory-domain-profile "test_Reg_Domain-DFS"


Radio Profiles

Radio profiles point to ARM (Adaptive Radio Management) Profiles.

Here we also enable beacon regulation to synchronize the timing of beacon advertisements.

rf dot11a-radio-profile "test_rf_radio-profile-dot11a"
 arm-profile "test_arm-profile-dot11a"


ARM Profiles

ARM (Adaptive Radio Management) Profiles automatically select the best channel and transmission power settings for each AP on your WLAN. Learn more here.

rf arm-profile "test_arm-profile-dot11a"
 max-tx-power 12

AP System Profiles

AP System Profiles are used to create HA controller pairs, defining both “LMS” (local mobility switch) IP address and the password used for syncing them.

It’s important to note there is more to the HA configuration as well.

ap system-profile "test_prof"
 bkup-passwords 1bc9120f3c9f85123123eff2e6794b4590cbdc64717c4e2a3

Traffic Management Profiles

This part of the configuration allows you to define traffic shaping policies.

The “fair-access” shaping policy forces airtime to be shared equally among all clients regardless of their capabilities (b,g,n,ac,etc).

wlan traffic-management-profile "TrafficShapingFair"
 shaping-policy fair-access

Regulatory Domain Profiles

This section sets the radio channels that can be used by clients. The channels that can be used in each country are subject to local law. Here we enable all the US channels.

ap regulatory-domain-profile "test_Reg_Domain-DFS"
 country-code US
 valid-11g-channel 1
 valid-11g-channel 6
 valid-11g-channel 11
 valid-11a-channel 36
 valid-11a-channel 40
 valid-11a-channel 44
 valid-11a-channel 48
 valid-11a-channel 52
 valid-11a-channel 56
 valid-11a-channel 60
 valid-11a-channel 64
 valid-11a-channel 100
 valid-11a-channel 104
 valid-11a-channel 108
 valid-11a-channel 112
 valid-11a-channel 116
 valid-11a-channel 132
 valid-11a-channel 136
 valid-11a-channel 140
 valid-11a-channel 144
 valid-11a-channel 149
 valid-11a-channel 153
 valid-11a-channel 157
 valid-11a-channel 161
 valid-11a-channel 165
 valid-11a-40mhz-channel-pair 36-40
 valid-11a-40mhz-channel-pair 44-48
 valid-11a-40mhz-channel-pair 52-56
 valid-11a-40mhz-channel-pair 60-64
 valid-11a-40mhz-channel-pair 100-104
 valid-11a-40mhz-channel-pair 108-112
 valid-11a-40mhz-channel-pair 132-136
 valid-11a-40mhz-channel-pair 140-144
 valid-11a-40mhz-channel-pair 149-153
 valid-11a-40mhz-channel-pair 157-161
 valid-11a-80mhz-channel-group 36-48
 valid-11a-80mhz-channel-group 52-64
 valid-11a-80mhz-channel-group 100-112
 valid-11a-80mhz-channel-group 132-144
 valid-11a-80mhz-channel-group 149-161

Virtual AP Configuration Examples

Virtual AP Example 1: psktest (Basic WPA2 PSK):

This SSID is a simple WPA2 PSK network, where all users get assigned to the same vlan.

Virtual-AP Configuration

The Virtual-AP contains the configuration for an SSID.

Here we set the aaa-profile (which defines which ACLs get applied), the ssid-profile (ssid name & psk), and vlan assignment.

The broadcast-filter all option drops all multicast and broadcast traffic in the air. Band-steering tries to force clients onto the preferred 5 GHz band, but allows them to connect to 2.4 GHz if unable.

wlan virtual-ap "vap_psktest"
 aaa-profile "default-dot1x-psk"
 ssid-profile "ssid_psktest"
 broadcast-filter all

SSID Profile

Used to define minimum rates, the broadcast SSID, and the PSK.

Here we set the lowest supported rates to 12 mbps, for 5 GHz and 2.4 GHz respectively. This removes support for very old clients (802.11b), which can help improve performance.

wlan ssid-profile "ssid_psktest"
 essid "psktest"
 opmode wpa2-psk-aes
 a-basic-rates 12 18 24
 a-tx-rates 12 18 24 36 48 54
 g-basic-rates 12 18 24
 g-tx-rates 12 18 24 36 48 54
 wpa-passphrase 78a785789845d3d07deed9516c54e5627e237e3cb19335b3604538eecb61102c

AAA Profiles

Here we define the role the user is assigned, which in turn defines the ACLs applied to them.

The defualt-psk authentication mode is built-in to ArubaOS, and it tells the controller to authenticate using the wpa-passphrase assigned above.

aaa profile "default-dot1x-psk"
   initial-role "authenticated"
   authentication-dot1x "default-psk"


The user role defines the ACLs assigned to users on this SSID.

user-role authenticated
 access-list session global-sacl
 access-list session apprf-authenticated-sacl
 access-list session ra-guard
 access-list session allowall

ACLs applied to the Authenticated User Role

The first two ACLs are predefined, and are empty by default.

global-sacl applies to all user roles, and  apprf-authenticated-sacl was created when the new user role was defined.

ra-guard is intended to prevent wireless clients from becoming IPv6 Routers. allowall permits all ipv4 and ipv6 traffic.

ip access-list session global-sacl  
ip access-list session apprf-authenticated-sacl
ip access-list session ra-guard 
 ipv6  user any icmpv6 rtr-adv  deny 
ip access-list session allowall 
  any any any  permit 
  ipv6  any any any  permit

Virtual AP Example 2: authtest – 802.1x authentication via a RADIUS Server

This SSID has a more complex 802.1x configuration.

In the 802.1x authentication process, a RADIUS server is queried and upon successful authentication returns a variable which is used to place users in the correct user-role. In this way you can have different users assigned to different VLANs.

Virtual-AP Configuration

Here we place users in a NULL vlan (666) during the 802.1x authentication process, where they are essentially black holed until authentication completes.

Unlike our last config, this SSID is only broadcast on the “a band” (5 GHz).

wlan virtual-ap "vap_authtest"
 aaa-profile "aaa_authtest"
 ssid-profile "ssid_authtest"
 vlan 666
 allowed-band a
 steering-mode force-5ghz
 broadcast-filter all


SSID Profile

Used to define minimum rates and broadcast SSID, just like our last config.

wlan ssid-profile "ssid_authtest"
 essid "authtest"
 opmode wpa2-aes
 a-basic-rates 12 18 24
 a-tx-rates 12 18 24 36 48 54
 g-basic-rates 12 18 24
 g-tx-rates 12 18 24 36 48 54

AAA Profiles

This time we connect to a RADIUS server to authenticate. The RADIUS server returns an attribute which is used to assign the user to the correct role.

Here we define the RADIUS server groups which we are authenticating against.

aaa profile "aaa_authtest"
authentication-dot1x "dot1x_authtest"
dot1x-server-group "radius"
radius-accounting "radius"

802.1x Settings

Nothing is defined here.

aaa authentication dot1x "dot1x_authtest"

AAA Server Settings

Here we define our RADIUS server’s IP addresses and passwords, and we place them in a server-group with instructions to load balance across them.

aaa server-group "radius"
 auth-server radius1
 auth-server radius2
aaa authentication-server radius "radius1"
 host ""
 key 78b18f4e47e8c113bef38c91231345aff1c7e2cbc6b3958cb
aaa authentication-server radius "radius2"
 host ""
 key 84c519342621c863asdfe451920f9e47bb54aeb89ecf73d4

User-Role Settings

This is the role we will assign the user, based on the attribute received by the RADIUS server (in this case, “systems”).

The role defines the VLAN assignment and the ACLs applied. The same ACLS as above are used.

user-role systems
 access-list session global-sacl
 access-list session apprf-systems-sacl
 access-list session ra-guard
 access-list session allowall



And that’s all there is to it. Hopefully someone will finds this useful when getting started with ArubaOS!