ArubaOS Mobility Lab

Abstract

First day impressions with Aruba Mobility Conductor.

I spent the day standing up an ArubaOS 8 lab. I’d never touched the platform before. The goal wasn’t to become fluent in their CLI (very similar to Cisco IOS, btw).  It was an exercise to understand the architecture and compare it to familiar technology. 

Limitations

Lab Roles

The Conductor manages configuration, while the controller handles wireless network operations. Aruba's AOS 8 documentation confirms that division.

MM: Mobility Master / Mobility Conductor

This is the management and orchestration brain.

N.B., Aruba renamed Mobility Master to Mobility Conductor.

CHR: MikroTik Cloud Hosted Router

Table 2
Lab Nodes, interfaces, VLANs, and IPs

Node	Interface	VLAN	IP Address	Purpose
MM	GE 0/0/0	20	10.10.10.2/24	Aruba Control-Plane
MM	mgmt	Untagged	172.16.42.65/24	OOB management
vMC	GE 0/0/0	20	10.10.10.3/24	Aruba Control-Plane
vMC	mgmt	Untagged	172.16.42.66/24	OOB management
CHR	ether3_aruba	110, 120, 130	NA	Mobility trunk
CHR	vlan110	110	10.110.0.1/24	Corporate WLAN gateway
CHR	vlan120	120	10.120.0.1/24	Guest WLAN gateway
CHR	vlan130	130	10.130.0.1/24	IoT WLAN gateway

Note. The conductor and controller communicate over VLAN 20. Dedicated management interfaces connect separately to the management network. The CHR provides Layer 3 gateways for the corporate, guest, and IoT wireless VLANs.

Registration and the trust relationship

Registration between the MM and vMC initially failed.  The process required matching IPsec pre-shared keys from the /mm context:

cd /mm
configure terminal
localip 10.10.10.3 ipsec <matching-PSK>
write memory

After that, the IKEv2/IPsec SAs came up and the Conductor accepted the vMC as a managed device. 

Aruba Structure

The Mobility Conductor holds a hierarchy of system nodes, groups, and individual device nodes. 

Configuration inheritance flows downward through the hierarchy, from the root node to its child nodes. Each child inherits its parent's configuration while allowing more specific settings or overrides at the group or individual device level.

Table 2.
Configuration Inheritance

Configuration location	Scope
/	Global configuration
/md	All managed devices
/md/LAB	LAB group-specific devices
/md/LAB/00:15:5d:e7:09:1d	Individual vMC configuration
/mm/mynode	Mobility Conductor-specific configuration

Mobility Conductor-specific 

We can define all nodes from the root.  But we can also create exceptions at the group or device level. Note everything is overridable.  

configure terminal applies to whatever node you’re currently in. Change the node first and the same command lands in a different scope. Configuration defined at /md/LAB is inherited by devices beneath it.  The device node itself can create some exceptions at the group or device level.

That inheritance model is native. It is not something you have to assemble from modules the way you do in Terraform or OpenTofu. IaC methodology can provide similar results through explicit references, but Aruba builds the hierarchy into the system.

Composition Rules

Inheritance decides where the configuration belongs in the hierarchy. Composition decides how wireless objects are configured. 

I configured composition rules for each SSID. Its configuration was composed into separate profiles.  The AP group references a Virtual AP, which in turn references the SSID and AAA objects:

CORP-AP-GRP
    └── CORP-VAP
         ├── CORP-SSID (WPA2-PSK-AES)
         ├── CORP-AAA (authentication-dot1x default)
         └── VLAN 110

Note, two dependency issues: It rejected WPA2-PSK-AES mode until a pre-shared key was added. It also rejected the SSID profile until its AAA profile included an 802.1X profile (even though the SSID used PSK).

After the commit, we validate that the group-defined profiles resolved into the vMC’s configuration:  

show configuration effective

That confirmed inheritance. It did not prove the running controller had fully applied the change.

Mapping similar technology

The Conductor hierarchy and the wireless object model had a familiar feel to similar technology.

Concept	ArubaOS 8	Terraform / OpenTofu	MikroTik CAPsMAN	Juniper WLC
Central management	Mobility Conductor	GIT Repository	CAPsMAN controller	WLC or Ringmaster
Shared configuration	Config groups	Shared modules	Profiles	Profiles
Devices	Device nodes	Device and/or root modules	Managed CAPs	Managed APs
Reusable objects	SSID, AAA, VAP profiles	Modules and resources	Security, channel, datapath profiles	SSID, security, and radio profiles
Configuration inheritance	Parent-to-child nodes	Explicit module composition and variables	Profile assignment/ provisioning	Profile assignments
Deployment	Conductor to controller	Orchestration scripts	Provision APs	Provision APs

Aruba’s hierarchy is native. Terraform and OpenTofu give you the framework to build something similar, but you have to supply the structure yourself. Juniper’s WLC and CAPsMAN sit closer to the operational side of the comparison.  Both push wireless configuration to APs.  Both lean hard on policy and templates over configuration inheritance.

The Next Lab

The next step would expand the lab beyond wireless management and explore Aruba's broader architecture.

I'd introduce a second managed gateway on a separate routed network, to examine remote-site connectivity, VPN concentration, and SD-WAN path selection. 

I'd also like to integrate Aruba ClearPass Policy Manager to explore their centralized authentication, role-based access control, and dynamic policy enforcement through RADIUS and 802.1X. 

Finally, I'd like to compare the AOS 8 architecture with AOS 10 and Aruba Central. The goal would be to understand the architecture, operational benefits, and tradeoffs.