Blog

Part 1 established that AOS 8 splits the network into a management layer — the Mobility Conductor (formerly Mobility Master) — and a control/data layer of Mobility Controllers, which the Conductor calls managed devices (MDs). This post builds that management layer: which platforms exist, how the configuration tree works, how a controller joins the Conductor, how controller ports and VLANs are set up, how the Conductor is made redundant, and how licences are pooled.

Roles a Device Can Play in AOS 8

The same AOS 8 software image runs on every controller platform, and the role is selected in the initial setup dialog:

A device’s role cannot be changed on the fly — switching between standalone and MD means writing the configuration off and re-running the setup dialog (write erase all followed by a reload).

Platforms and Sizing

Mobility Conductor

The Conductor is sized by the number of devices (APs plus controllers) it manages. Virtual appliances have historically been sold as MM-VA-50, MM-VA-500, MM-VA-1K, MM-VA-5K and MM-VA-10K, and hardware appliances as MM-HW-1K, MM-HW-5K and MM-HW-10K. A virtual Conductor is licensed for its capacity; the VM’s vCPU, memory and disk must match Aruba’s sizing table for that capacity, otherwise services such as AirMatch run slowly or fail. Production Conductors are always deployed in pairs.

Mobility Controllers

Indicative capacities from Aruba’s datasheets are shown below — they vary slightly by release, so always check the current datasheet before sizing. Remember that clustering with redundancy halves usable capacity (Part 6).

Client counts are only half of sizing. Tunnel mode makes the controller decrypt every wireless frame, so encrypted throughput (published per model) often becomes the real limit long before AP or client counts are reached — especially with Wi-Fi 6/6E/7 APs.

The Configuration Hierarchy

Everything configured on a Conductor lives somewhere in a tree of configuration nodes. Understanding this tree is the key skill of AOS 8: every command is entered at a node, applies to that node and everything beneath it, and can be overridden lower down.

• / — the root. Holds factory defaults and anything that must apply everywhere, including Conductors.
• /mm — common configuration for the Conductors themselves; /mm/mynode is the node for the Conductor currently logged into (its own IPs, VRRP, redundancy).
• /md — parent of every managed device. Administrators create group nodes beneath it to mirror geography or organization: /md/USA, /md/USA/HQ, /md/USA/Branch.
• Device nodes — the leaves, one per managed device, identified by MAC address. They hold only what must be unique per box: hostname, VLAN interface IPs, port settings, default gateway.

Inheritance Rules

1. A device receives the merged configuration of every node from / down to its own device node. This merged result is called the effective configuration.
2. A profile defined at a lower node with the same name as one higher up overrides the inherited version for that branch.
3. A profile created at a lower node is invisible to sibling branches. A WLAN defined at /md/USA/HQ does not exist at /md/USA/Branch.
4. Some commands are only valid at certain levels — interface IP addresses only on device nodes, Conductor redundancy only under /mm/mynode.

The design rule that follows: define things as high as they are common, and no higher. A corporate 802.1X SSID used worldwide belongs at /md; a site-specific guest portal belongs at the site node; IP addresses belong at the device node. Configuration placed too low is duplicated and drifts; configuration placed too high leaks into places it should not be.

Navigating the Tree in the CLI

The Conductor CLI prompt shows the current node in square brackets. The cd command moves around the tree just like a filesystem:

(MCR-1) [mynode] #show configuration node-hierarchy

Default-node is not configured. Autopark is disabled.

Configuration node hierarchy
----------------------------
Config Node                  Type    Name
-----------                  ----    ----
/                            System
/md                          System
/md/USA                      Group
/md/USA/HQ                   Group
/md/USA/HQ/00:1a:1e:00:00:01 Device  HQ-MC1
/md/USA/HQ/00:1a:1e:00:00:02 Device  HQ-MC2
/md/USA/Branch               Group
/mm                          System
/mm/mynode                   System

(MCR-1) [mynode] #cd /md/USA/HQ
(MCR-1) [HQ] #configure terminal
(MCR-1) [HQ] (config) #

Pending Changes and write memory

Configuration typed on the Conductor is not sent to controllers immediately. It accumulates as pending changes at the node where it was entered, and is committed and pushed to every affected managed device only when write memory is issued. In the WebUI the same idea appears as the Pending Changes button and Deploy changes.

(MCR-1) [HQ] (config) #wlan ssid-profile HQ-Guest-ssid
(MCR-1) ^[HQ] (config-submode)#essid "HQ-Guest"
(MCR-1) ^[HQ] (config-submode)#exit
(MCR-1) ^[HQ] (config) #show configuration pending

Pending changes
---------------
node:/md/USA/HQ
 wlan ssid-profile "HQ-Guest-ssid"
  essid "HQ-Guest"
 !

(MCR-1) ^[HQ] (config) #write memory
Saving Configuration...
Configuration Saved.

The ^ in front of the node name is a reminder that uncommitted changes exist. This two-step model is a safety net: a whole set of related changes (SSID, AAA profile, virtual AP, AP group) can be built and reviewed before any controller sees a half-finished configuration.

Reading Configuration at Different Levels

When a profile “does not behave as configured”, the first question is always which node won. show configuration effective detail answers it.

Creating Nodes and Moving Devices

! Create a group node, optionally cloning another node's configuration
(MCR-1) [mynode] (config) #configuration node /md/USA/Branch
(MCR-1) [mynode] (config) #configuration node /md/USA/Lab clone-from /md/USA/HQ

! Move a device: remove it from its old node, then add it under the new one
(MCR-1) [mynode] (config) #no configuration device 00:1a:1e:00:00:09
Warning: Device 00:1a:1e:00:00:09 will be reloaded, if present
(MCR-1) [mynode] (config) #configuration device 00:1a:1e:00:00:09 device-model A7010 /md/USA/Branch
(MCR-1) [mynode] (config) #write memory

Moving a device reloads it, because its entire effective configuration changes. Plan moves like any other outage.

Onboarding a Managed Device

Joining a controller to the Conductor takes two halves: the Conductor must expect the device, and the device must know how to reach the Conductor.

Step 1 — Prepare the Conductor

Create the device’s node and authorize it to build the IPsec management tunnel. The tunnel can be authenticated with a pre-shared key (per device MAC, per IP, or a global key) or with the controller’s factory certificate.

(MCR-1) [mynode] (config) #configuration node /md/USA/HQ
(MCR-1) [mynode] (config) #configuration device 00:1a:1e:00:00:01 device-model A7210 /md/USA/HQ

! IPsec authorization — choose ONE approach
(MCR-1) [mynode] (config) #local-peer-mac 00:1a:1e:00:00:01 ipsec Str0ngPSK-2026   ! per-device PSK (by MAC)
(MCR-1) [mynode] (config) #localip 0.0.0.0 ipsec Str0ngPSK-2026                    ! global PSK for any MD

(MCR-1) [mynode] (config) #write memory

Per-MAC entries are preferred for branch controllers with DHCP or multiple uplinks, because their source IP may change; a global localip 0.0.0.0 key is convenient in a lab but lets any device that knows the key join. Certificate-based authentication removes the shared secret altogether.

Step 2 — Run the Setup Dialog on the Controller

A factory-default controller boots into an interactive setup dialog on its console (or a web setup wizard). The prompts below are from AOS 8; values in angle brackets are examples.

Auto-provisioning is in progress. Choose one of the following options to override or debug auto-provisioning...
    'enable-debug'  : Enable auto-provisioning debug logs
    'disable-debug' : Disable auto-provisioning debug logs
    'mini-setup'    : Stop auto-provisioning and start mini setup dialog for controller role
    'full-setup'    : Stop auto-provisioning and start full setup dialog for any role
Enter Option (partial string is acceptable): full-setup

Enter System name [Aruba7210]: HQ-MC1
Enter Switch Role (standalone|md) [md]: md
Enter IP type to terminate IPSec tunnel (ipv4|ipv6) [ipv4]: ipv4
Enter Master switch IP address or FQDN: 10.1.10.10
Enter Master switch TYPE?(MM|ACP) [MM]: MM
Is this a VPN concentrator for managed device to reach Master switch (yes|no) [no]: no
This device connects to Master switch via VPN concentrator (yes|no) [no]: no
Master switch Authentication method (PSKwithIP|PSKwithMAC|...) [PSKwithIP]: PSKwithMAC
Enter IPSec Pre-shared Key: ************
Re-enter IPSec Pre-shared Key: ************
Do you want to enable L3 Redundancy (yes|no) [no]: no
Enter Uplink VLAN ID [1]: 10
Enter Uplink port [GE 0/0/0]: GE 0/0/0
Enter Uplink port mode (access|trunk) [access]: trunk
Enter Native VLAN ID [1]: 1
Enter Uplink VLAN IP assignment method (dhcp|static|pppoe) [static]: static
Enter Uplink VLAN Static IP address [172.16.0.254]: 10.1.10.21
Enter Uplink VLAN Static IP netmask [255.255.255.0]: 255.255.255.0
Enter IP Default gateway [none]: 10.1.10.1
Enter DNS IP address [none]: 10.1.1.53
Do you wish to configure IPV6 address on vlan (yes|no) [yes]: no
Enter Country code (ISO-3166), <ctrl-I> for supported list: US
You have chosen Country code US for United States (yes|no)?: yes
Enter the controller's IANA Time zone [America/Los_Angeles]: America/Los_Angeles
Enter Time in UTC [hh:mm:ss]: ...
Enter Date (MM/DD/YYYY): ...
Do you want to create admin account (yes|no) [yes]: yes
Enter Password for admin login (up to 32 chars): ************
Re-type Password for admin login: ************

Do you wish to save the configuration and reboot the switch (y|n): y

A few prompts deserve explanation:

• Master switch IP — in production this is the Conductor pair’s VRRP virtual IP, never an individual Conductor.
• Master switch TYPE — MM for an on-premises Conductor; ACP refers to Aruba Central On-Premises in releases that support it.
• VPN concentrator questions — answered yes on a branch controller that reaches the Conductor through a VPNC over the internet.
• Authentication method — must match how the Conductor was prepared: PSKwithIP pairs with localip, PSKwithMAC with local-peer-mac; certificate options exist for factory and custom certificates.
• L3 Redundancy — enables a secondary Conductor pair at another site (covered below).

The values entered here become the device’s only local configuration, equivalent to the masterip command:

masterip 10.1.10.10 ipsec Str0ngPSK-2026 interface vlan 10

Zero Touch Provisioning

Instead of a console session, a factory-default controller can be provisioned automatically (“auto-provisioning” in the banner above). The usual path is Aruba Activate, now part of Aruba Central/GreenLake: the controller’s serial number is mapped to a rule containing the Conductor address, node path and authentication method, and the controller fetches it over the internet at first boot. ZTP is how large retailers bring up hundreds of branch controllers shipped straight from the factory.

Step 3 — Verify

(MCR-1) [mynode] #show switches

All Switches
------------
IP Address   IPv6 Address  Name    Location           Type    Model         Version         Status  Configuration State  Config Sync Time (sec)  Config ID
----------   ------------  ----    --------           ----    -----         -------         ------  -------------------  ----------------------  ---------
10.1.10.11   None          MCR-1   Building1.floor1   master  ArubaMM-VA    8.12.0.x_xxxxx  up      UPDATE SUCCESSFUL    0                       42
10.1.10.12   None          MCR-2   Building1.floor1   standby ArubaMM-VA    8.12.0.x_xxxxx  up      UPDATE SUCCESSFUL    0                       42
10.1.10.21   None          HQ-MC1  Building1.floor1   MD      Aruba7210     8.12.0.x_xxxxx  up      UPDATE SUCCESSFUL    3                       42
10.1.10.22   None          HQ-MC2  Building1.floor1   MD      Aruba7210     8.12.0.x_xxxxx  up      UPDATE SUCCESSFUL    3                       42

Total Switches:4

A device stuck in down usually has an IPsec problem (wrong key, wrong authentication method, missing peer entry, or UDP 500/4500 blocked). A device that is up but shows UPDATE FAILED or CONFIG FAILURE accepted the tunnel but rejected part of its configuration — show switches debug and the MD’s error log explain which command failed. Useful additional checks are show crypto isakmp sa and show crypto ipsec sa on both ends.

Working on a Managed Device

Day-to-day configuration is done on the Conductor, but troubleshooting happens on the MD, where the APs and users actually live. From the Conductor, cd into a device node and use mdc to open that controller’s CLI without a separate SSH session. On the MD, most hierarchical configuration is read-only. If the Conductor is unreachable and an emergency change cannot wait, disaster-recovery on temporarily unlocks local configuration on the MD; those local changes are discarded when the MD re-syncs with the Conductor, so they must be replicated on the Conductor afterwards.

Controller Interfaces, VLANs and Trusted Ports

A controller is also a Layer 2/3 switch, and its port configuration has one Aruba-specific twist: the notion of trusted and untrusted ports and VLANs.

• Traffic arriving on a trusted port/VLAN is treated as infrastructure traffic and switched or routed normally.
• Traffic arriving on an untrusted port/VLAN is treated as user traffic: the source is entered into the user table, placed in a role, and subjected to the firewall — exactly like a wireless client.

Uplinks to the core must be trusted. Untrusted wired ports are how a controller can authenticate wired users directly, and in AOS 8 untrusted VLANs are also used for wired users tunnelled from Aruba switches (user-based tunnelling).

Typical device-node configuration for a campus controller with a single LACP uplink pair to the core:

(MCR-1) [mynode] #cd /md/USA/HQ/00:1a:1e:00:00:01
(MCR-1) [00:1a:1e:00:00:01] #configure terminal

hostname HQ-MC1
vlan 10
vlan 20
vlan 30
!
interface port-channel 0
    description "To core"
    trusted
    trusted vlan 1-4094
    switchport mode trunk
    switchport trunk allowed vlan 10,20,30
!
interface gigabitethernet 0/0/0
    lacp group 0 mode active
interface gigabitethernet 0/0/1
    lacp group 0 mode active
!
interface vlan 10
    ip address 10.1.10.21 255.255.255.0
!
controller-ip vlan 10
ip default-gateway 10.1.10.1
!
write memory

Note what is absent: no IP addresses on VLANs 20 and 30. In a typical design the controller is a Layer 2 device for user VLANs — the core switch or firewall is the default gateway and the DHCP relay. Giving the controller an IP in a user VLAN is only necessary if the controller itself must route, run DHCP, or source traffic in that VLAN. controller-ip pins the address the controller uses for AP termination, RADIUS, and its own identity; without it, the controller picks one, which can change when interfaces change.

Common Group-Level Settings

NTP, DNS, syslog, SNMP, administrative authentication and banners are usually set once at /md or at a regional node:

(MCR-1) [mynode] #cd /md
(MCR-1) [md] (config) #ntp server 10.1.1.123
(MCR-1) [md] (config) #clock timezone America/Los_Angeles
(MCR-1) [md] (config) #ip name-server 10.1.1.53
(MCR-1) [md] (config) #ip domain-name corp.example
(MCR-1) [md] (config) #logging 10.1.1.200
(MCR-1) [md] (config) #write memory

Accurate time matters more than usual on an Aruba network: certificate validation for CPsec and EAP-TLS, RADIUS accounting, and log correlation across Conductor, controllers and ClearPass all break subtly when clocks drift.

Mobility Conductor Redundancy

Two forms of redundancy protect the Conductor:

Layer 2 Redundancy (Active/Standby Pair)

Two Conductors on the same subnet share a VRRP virtual IP. The active one owns the VIP and serves configuration; the standby receives a periodic synchronization of the configuration database (and optionally RF plan data) and takes over the VIP if the active fails. Each Conductor’s redundancy configuration is entered under its own /mm/mynode:

! On MCR-1 (repeat on MCR-2 with its own priority and the peer IP of MCR-1)
(MCR-1) [mynode] (config) #vrrp 10
(MCR-1) ^[mynode] (config-submode)#ip address 10.1.10.10
(MCR-1) ^[mynode] (config-submode)#vlan 10
(MCR-1) ^[mynode] (config-submode)#priority 110
(MCR-1) ^[mynode] (config-submode)#tracking master-up-time 30 add 20
(MCR-1) ^[mynode] (config-submode)#no shutdown
(MCR-1) ^[mynode] (config-submode)#exit

(MCR-1) ^[mynode] (config) #master-redundancy
(MCR-1) ^[mynode] (config-submode)#master-vrrp 10
(MCR-1) ^[mynode] (config-submode)#peer-ip-address 10.1.10.12 ipsec Peer-PSK-2026
(MCR-1) ^[mynode] (config-submode)#exit

(MCR-1) ^[mynode] (config) #database synchronize period 30
(MCR-1) ^[mynode] (config) #database synchronize rf-plan-data
(MCR-1) ^[mynode] (config) #write memory

• tracking master-up-time 30 add 20 raises the VRRP priority of a Conductor that has been active for 30 minutes, so that a recovering peer does not snatch the VIP back and cause a needless second failover.
• database synchronize period sets how often (in minutes) the standby is refreshed. A change made seconds before a failover may be missing on the new active, which is why a final manual database synchronize before maintenance is good practice.
• Both Conductors must run the same software version and should have the same VM sizing.

Verify with show master-redundancy, show vrrp and show database synchronize — the last shows the time and result of the most recent sync.

Layer 3 Redundancy (Disaster Recovery)

Large organizations often add a second Conductor pair in another data centre. The primary pair synchronizes its database across the routed network to the secondary pair, and managed devices are configured (the L3 Redundancy prompt in the setup dialog) with both pairs’ addresses. If the entire primary site is lost, MDs fail over to the secondary pair. Because the Conductor is not in the data path, even this failover is invisible to users; it only restores the ability to manage the network.

Centralized Licensing

In AOS 8, licences are installed on the Conductor — never on the managed devices — and consumed from pools.

• Global pool — by default every licence is in one pool shared by the whole tree.
• Dedicated pools — a group node can be given its own pool, carved out of the global pool, guaranteeing capacity for a region or business unit (and stopping one branch from consuming everyone’s licences).
• Consumption — an AP consumes AP, PEF and RFP licences when it comes up on a controller. When a pool runs dry, new APs come up but are flagged as unlicensed and do not broadcast SSIDs.
• Grace — if MDs lose contact with the Conductor they keep their current licence allocation for a defined period, so a Conductor outage does not immediately strand APs.

(MCR-1) [mynode] #show license                      ! installed keys
(MCR-1) [mynode] #show license-usage                ! consumption per licence type
(MCR-1) [mynode] #show license-pool-profile-root    ! global pool settings

! On the MD, unlicensed APs show the L flag
(HQ-MC1) #show ap database long
Flags: ... L = Unlicensed ...

A classic AOS 8 lab problem: licences are installed, but APs still show the L flag. The cause is almost always the pool configuration — for example a dedicated pool created for a node but left empty. show license-pool-profile-root on the Conductor reveals it.

Design Checklist

• Deploy the Conductor as a redundant pair, sized for growth, and point MDs at the VIP.
• Mirror geography or organization in the node tree; keep it shallow (three or four levels) and predictable.
• Put shared WLANs, roles and AAA at /md; site specifics at the site node; only per-box values on device nodes.
• Use controller-ip on every MD and trust the uplinks.
• Use per-MAC PSKs or certificates for MD authentication; avoid a global PSK in production.
• Configure NTP everywhere before anything certificate-based.
• Use dedicated licence pools where business units must not compete for capacity.
• Remember that the Conductor version must be equal to or newer than every MD’s version — upgrade the Conductor first.

Exercises

1. An SSID profile named Corp-ssid is defined at /md with opmode wpa2-aes. A profile with the same name is defined at /md/USA/Branch with opmode wpa3-aes-ccm-128. Which opmode does a controller at /md/USA/HQ use, and which does a controller at /md/USA/Branch use? How can this be confirmed from the CLI?

2. An engineer adds a WLAN on the Conductor, logs out for the day, and the next morning users report the new SSID is missing. What was most likely forgotten?

3. A new branch controller with a DHCP-assigned uplink address will not come up on the Conductor. The Conductor was prepared with localip 10.20.30.40 ipsec Key123456. What is wrong and what is a better approach?

4. Write the device-node configuration for a controller whose only uplink is GE 0/0/2, carrying management VLAN 100 (IP 192.168.100.5/24, gateway .1) and user VLANs 200 and 300, with VLAN 100 untagged.

vlan 100
vlan 200
vlan 300
interface gigabitethernet 0/0/2
    trusted
    trusted vlan 1-4094
    switchport mode trunk
    switchport trunk native vlan 100
    switchport trunk allowed vlan 100,200,300
interface vlan 100
    ip address 192.168.100.5 255.255.255.0
controller-ip vlan 100
ip default-gateway 192.168.100.1

5. The active Conductor fails at 10:05. The last database sync was at 10:00, and an engineer had committed a new role at 10:03. What happens to that role, and what operational habit prevents the surprise?

6. Why should the Conductor be upgraded before the managed devices?

Summary

The Mobility Conductor holds the entire AOS 8 configuration in a tree rooted at /, with Conductors under /mm and managed devices under /md. Configuration is inherited down the tree, overridden by same-named profiles lower down, and only pushed to controllers on write memory. A managed device joins by building an IPsec tunnel to the Conductor’s VIP using a PSK or certificate configured in its setup dialog, after which everything else — including its VLAN interfaces and ports, configured on its device node — arrives from above. Controller uplinks are trusted ports; untrusted ports and VLANs subject traffic to the user firewall. Conductors run as VRRP-protected pairs with database synchronization, optionally backed by a second pair for disaster recovery, and they own centralized licence pools that APs draw from.

Next: Part 3 moves down to the access points — hardware, the boot and controller-discovery process, AP groups and provisioning, AP modes, control plane security and the tunnels between AP and controller.