Blog

Aruba — today HPE Aruba Networking — is one of the two dominant enterprise Wi-Fi vendors, and its controller-based architecture is found in universities, hospitals, airports, warehouses and corporate campuses all over the world. The platform has a reputation for being powerful but initially confusing: there are several operating systems, three or four ways to deploy the same access point, and a vocabulary (Mobility Conductor, MD, AAC, UAC, VAP, PEF, AirMatch…) that has to be learned before any configuration makes sense.

This series builds that vocabulary from the ground up and then uses it. Part 1 is the map: what each product does, how the pieces fit together, which operating system does what, and where user traffic actually flows. The later parts go deep on each component with real CLI configuration, diagrams, and exercises.

The series focuses on ArubaOS 8 (AOS 8) — the on-premises controller platform that most enterprise networks still run and that Aruba’s mobility certifications are built on — and points out where AOS 10 and Instant behave differently. Readers new to Wi-Fi itself may want to start with the fundamentals posts on this site first: WLAN Fundamentals, Radio Frequency Band, and Spectrum Management, QoS and RSN/WPA2.

A Short History, and Why Names Keep Changing

Aruba Networks was founded in 2002 around one idea that was radical at the time: thin access points tunnelling all user traffic back to a central controller, where security policy is enforced by a stateful firewall that knows who the user is rather than merely which port or VLAN the traffic arrived on. That “user-centric” firewall is still the heart of the platform twenty years later.

HPE acquired Aruba in 2015, and in 2023 the brand became HPE Aruba Networking. Along the way the software went through three major generations, and the terminology changed with each one. In recent AOS 8 releases Aruba also replaced the terms master and local, so the same box can appear under different names depending on which document or software release is being read:

Older term	Current term	Meaning
Mobility Master (MM)	Mobility Conductor (MCR)	The AOS 8 management server that configures and licenses controllers
Master controller	Conductor controller	In AOS 6, the controller that held global configuration
Local controller	Member / managed device (MD)	A controller that receives its configuration from above
Mobility Controller (MC)	Mobility Controller, or Gateway in AOS 10	The appliance that terminates APs and users
Instant master / virtual controller	Conductor AP / virtual controller (VC)	The Instant AP elected to manage its cluster
masterip (CLI)	masterip / conductorip	Command on a managed device pointing at its Conductor

This series uses Mobility Conductor and managed device (MD), with the old name in brackets where it helps — older screenshots, forum posts and many production CLIs still say “Mobility Master” and the prompt still reads [mynode].

The Building Blocks

An Aruba wireless network is assembled from a small set of components. Not every deployment uses all of them, but every deployment uses some subset of this list.

Access Points

The AP is the radio. It converts 802.11 frames to something that can travel over a wire and back. Modern Aruba APs are universal: the same hardware model can boot as a controller-managed Campus AP, as a Remote AP across the internet, as a controllerless Instant AP, or as an AOS 10 AP managed from the cloud. What an AP becomes is decided at boot time by what it discovers on the network — Part 3 walks through that process step by step.

Model numbers follow a pattern. The first digit marks the generation (2xx = Wi-Fi 5 wave 1 era, 3xx = Wi-Fi 5 wave 2, 5xx = Wi-Fi 6, 6xx = Wi-Fi 6E, 7xx = Wi-Fi 7), and within a generation higher numbers mean more radios, more spatial streams and more features. An H suffix denotes a wall-plate hospitality AP and an R suffix a remote/teleworker model; outdoor models sit in their own sub-ranges (for example the 57x family).

Mobility Controllers (Gateways)

A Mobility Controller is a purpose-built appliance (or virtual machine) that:

• terminates the control channel and GRE data tunnels from APs,
• acts as the 802.1X authenticator and RADIUS client,
• decrypts wireless traffic in tunnel mode,
• runs the Policy Enforcement Firewall (PEF) — a stateful, role-based firewall applied to every user session,
• places users onto VLANs and forwards their traffic onto the wired network.

Hardware has spanned the 7000 series (branch: 7005, 7008, 7010, 7024, 7030), the 7200 series (campus and data centre: 7205, 7210, 7220, 7240XM, 7280) and the newer 9000/9100/9200-series gateways, which also run AOS 10 and SD-Branch. A virtual Mobility Controller (MC-VA) runs the same software on VMware ESXi, KVM or Hyper-V. In AOS 10 the same appliances are called gateways, and they become optional.

Mobility Conductor (formerly Mobility Master)

Introduced with AOS 8, the Mobility Conductor is a management and orchestration layer that sits above the controllers. It does not terminate APs or carry user traffic. Its jobs are:

• holding the hierarchical configuration for every controller and pushing it down,
• owning the centralized licence pools,
• running AirMatch (centralized RF channel and power planning) and centralized ClientMatch,
• orchestrating controller clusters, Live Upgrade and loadable service modules,
• providing a single dashboard for the whole network.

It ships as a virtual appliance (MM-VA, sized by the number of devices it manages) or a hardware appliance, and it is normally deployed as a redundant pair. Part 2 is devoted to it.

Instant and the Virtual Controller

Aruba Instant removes the controller entirely. A group of Instant APs on the same Layer 2 network elect one of themselves as the virtual controller (VC), which serves the management web UI, distributes configuration to the other APs, and can proxy RADIUS on behalf of the whole cluster so that the RADIUS server only needs to know one client address. User traffic is bridged locally at each AP. Instant scales to small and medium sites cheaply, and an Instant AP can later be converted into a Campus AP when the site outgrows it.

Do not confuse Aruba Instant with Aruba Instant On, a separate, simplified product line for small businesses that is managed from a phone app and shares little with the enterprise platform.

Aruba Central

Aruba Central (now part of HPE GreenLake) is Aruba’s cloud management platform. It can monitor and configure Instant clusters and switches, and it is the only management plane for AOS 10. Central also absorbed the old Aruba Activate service — the cloud zero-touch provisioning database that tells a factory-fresh AP or controller where to go when it first powers up.

ClearPass Policy Manager

ClearPass is Aruba’s network access control (NAC) and policy server: a RADIUS/TACACS+ server with profiling, guest portals, device onboarding, posture checks and an enforcement engine that returns roles to the controller. Any RADIUS server works with an Aruba controller, but ClearPass integrates most tightly — it can even push complete role definitions down to the controller (downloadable user roles). Part 5 covers the integration.

AirWave

AirWave is the legacy on-premises network management system for multi-vendor monitoring, RF heatmaps and reporting. Many AOS 6 and AOS 8 sites still run it, but its functions have largely moved to the Mobility Conductor dashboard and to Aruba Central.

Component	Main job	Form factors	Carries user traffic?
Access point	Radios; 802.11 to wire	Indoor, outdoor, hospitality, remote	Yes
Mobility Controller / Gateway	AP and user termination, firewall, VLANs	7000/7200/9000-series hardware, MC-VA	Yes (tunnel modes)
Mobility Conductor	Configuration, licensing, RF and cluster orchestration	MM-VA or hardware	No
Instant virtual controller	Manages an Instant cluster	A role inside one AP	Only its own clients
Aruba Central	Cloud management, AOS 10, ZTP	SaaS (on-premises edition exists)	No
ClearPass	AAA, NAC, guest, profiling, posture	Virtual or hardware	No
AirWave	Legacy monitoring and reporting	Virtual or hardware	No

Three Operating Systems: AOS 6, AOS 8 and AOS 10

AOS 6 — Master and Local Controllers

In ArubaOS 6 one controller was the master, holding global configuration such as WLAN profiles, roles and the AP whitelist, while local controllers received that global configuration and terminated APs. Each local still kept its own local configuration (interfaces, VLANs, IPs), so managing dozens of controllers meant logging into many of them. Redundancy relied on VRRP between a master and a backup master, and on primary/backup LMS (Local Management Switch) IPs for APs, with failover that typically dropped clients. AOS 6 reached end of software maintenance years ago but it still runs in some networks, and its concepts — master, LMS, AP group, virtual AP — survive in AOS 8.

AOS 8 — Conductor and Managed Devices

AOS 8 split management from the controllers. The Mobility Conductor holds all configuration in a tree; each controller becomes a managed device that boots with only enough local configuration to reach the Conductor and then inherits everything else. AOS 8 also introduced:

• Clustering — up to twelve controllers share AP and user load, with hitless failover for both (Part 6).
• AirMatch — RF planning computed centrally on the Conductor from the whole network’s view, replacing per-AP ARM decisions for channel and power (Part 7).
• Centralized licensing — licences live on the Conductor in pools.
• Live Upgrade — controllers and APs upgraded in rolling waves without a maintenance window.
• Loadable Service Modules (LSM) — services such as AirMatch, AppRF and UCC upgraded on the Conductor without rebooting it.
• MultiVersion — a Conductor can manage controllers running older AOS 8 releases (never newer ones).

AOS 8 also supports a standalone controller mode for small sites that do not justify a Conductor. A standalone controller holds its own configuration under a local hierarchy and cannot cluster with other controllers.

AOS 10 — Cloud-Managed APs and Optional Gateways

AOS 10 moves the management plane to Aruba Central and flips the old model around. APs connect directly to Central over HTTPS/WebSocket and are fully functional on their own: they authenticate users, enforce roles and bridge traffic locally. Gateways are only needed when traffic must be tunnelled — for example to put thousands of users from many buildings onto one large central VLAN, or to firewall them centrally. RF optimization (AirMatch) and client steering run in Central. In AOS 10, encryption always terminates at the AP, even for tunnelled SSIDs. Licensing is subscription-based (Foundation and Advanced tiers).

AOS 10 is not an upgrade of an AOS 8 controller in place; it is a different architecture. Migration means moving APs to Central and either repurposing compatible controllers as gateways or retiring them.

	Instant (AOS 8 IAP)	AOS 8 controller-based	AOS 10
Management plane	Virtual controller UI, Central or AirWave	Mobility Conductor (or standalone MC)	Aruba Central only
Control plane	Distributed in APs	Controllers	APs + Central (+ gateways)
User traffic	Bridged at each AP	Tunnelled to controllers (typically)	Bridged, tunnelled, or mixed per SSID
Where 802.11 is decrypted	AP	Controller (tunnel mode) or AP (decrypt-tunnel, bridge)	AP
Stateful role firewall	On the AP	On the controller (PEF)	On the AP or gateway
Scale	Small and medium sites per cluster	Thousands of APs per cluster; tens of thousands per Conductor	Very large; cloud scale
Typical fit	Branches, small campuses, cost-sensitive sites	Large campuses that want on-premises control	Cloud-first organizations, distributed enterprises

The Three Planes

Every network device has a management plane (how it is configured and monitored), a control plane (the protocols that make decisions) and a data plane (the forwarding of user packets). In AOS 8 these are deliberately spread across different boxes, and keeping them apart in one’s head explains most of the platform’s behaviour.

The consequence that matters most in production: if the Mobility Conductor goes offline, Wi-Fi keeps working. Controllers keep their last committed configuration, APs stay up, users keep authenticating and passing traffic. What stops is the ability to change configuration, plus centralized services such as AirMatch and Conductor-side ClientMatch decisions. That is why the Conductor is made redundant for convenience and for its services — not because its loss is an outage.

Losing a controller, on the other hand, affects the APs and users it was serving — which is exactly the problem clustering (Part 6) solves.

How User Traffic Flows: Forwarding Modes

The single most important design decision for each WLAN is its forwarding mode, configured per virtual AP profile. It determines where 802.11 encryption ends, where the user’s firewall policy is applied, and which VLAN the user lands on.

Mode	Where 802.11 is decrypted	Where user traffic exits	Typical use
tunnel	Controller	Controller VLAN	Default campus design: central firewall, one big user VLAN, easy roaming
decrypt-tunnel	AP	Controller VLAN	Same as tunnel but offloads crypto to the AP; allows inspection on the AP-controller path
bridge	AP	AP’s own switchport VLAN	Local breakout, very small sites, traffic that must stay local
split-tunnel	AP	Corporate subnets via tunnel; everything else locally	Remote APs at home offices and branches

Tunnel mode explains several things that confuse engineers coming from autonomous-AP networks. The AP’s switchport only needs the AP’s own management VLAN — not the user VLANs — because user frames arrive at the controller inside GRE. The user VLANs exist on the controller’s uplinks instead. Roaming between APs is trivial because the user’s IP address, VLAN and firewall state live on the controller, not on any single AP. And the controller’s encryption throughput is a real sizing factor, which is one reason AOS 8 added decrypt-tunnel mode and why AOS 10 decrypts at the AP. The earlier post on Aruba AP Tunnels and MultiZone looks at tunnels from the MultiZone angle; Part 3 of this series covers the tunnels in protocol-level detail.

The User-Centric Model: Roles, Not Ports

Traditional networks enforce policy by location: whoever plugs into VLAN 20 gets VLAN 20’s ACLs. Aruba enforces policy by identity. Every client is placed into a user role — employee, contractor, guest, printer, quarantine — and the role carries the firewall rules, bandwidth limits, VLAN and QoS for that client. The role can be assigned by default, derived from client attributes, or returned by the RADIUS server at authentication time, and it can be changed mid-session with a RADIUS Change of Authorization.

Two employees on the same SSID and the same VLAN can therefore have entirely different access, and a laptop that fails a posture check can be quarantined without moving it to another VLAN. This model is configured in Part 5, but it shapes everything from the very first WLAN, because every SSID needs to answer the question “which role does a client start in, and how does it get promoted?”

Licensing at a Glance

Licensing changed several times across the platform’s life, so the details depend on release and purchase date. The classic AOS 8 model has these licence types, all installed on the Mobility Conductor and consumed from centralized pools:

• AP — one per AP terminating on a controller; without it the AP does not serve clients.
• PEF (Policy Enforcement Firewall) — enables the full role-based firewall, user-defined roles and AppRF; normally one per AP.
• RFProtect (RFP) — wireless intrusion protection, rogue containment and spectrum analysis features.
• MM / MCR capacity — how many devices a virtual Conductor may manage.
• VIA, Web Content Classification (WebCC) and others for specific features.

Instant APs need no per-AP licence for basic operation. AOS 10 uses per-device subscriptions in Aruba Central. Part 2 shows how AOS 8 pools work and how to troubleshoot an AP stuck without a licence.

Choosing an Architecture

• A single small office, a few APs, no central IT team: Instant (or Instant On if very small). No controller to buy or maintain.
• Many branches with local internet breakout: Instant or AOS 10 managed from Central; Remote APs or branch gateways where corporate traffic must be tunnelled.
• A large campus with on-premises requirements (air-gapped, regulated, or simply an existing investment): AOS 8 with a redundant Mobility Conductor pair and controller clusters.
• A large campus that is comfortable with SaaS management: AOS 10, with gateways only where tunnelling is required.
• A single site with one or two controllers and no Conductor budget: AOS 8 standalone controller, accepting the loss of clustering and AirMatch.

Building a Home Lab

Aruba is unusually lab-friendly because both the Conductor and the controller exist as virtual appliances with evaluation licences:

1. Hypervisor: VMware ESXi, KVM/Proxmox or Hyper-V on a machine with roughly 16 GB of free RAM. A virtual Conductor (MM-VA) and one or two virtual controllers (MC-VA) fit comfortably.
2. Images and licences: AOS 8 images come from the HPE Networking Support Portal; evaluation licences enable AP, PEF and RFP features for a limited period.
3. A real AP: a used Wi-Fi 5 or Wi-Fi 6 Campus/universal AP (AP-303, AP-315, AP-505, AP-515…) is inexpensive second-hand and is all that is needed to make real SSIDs. Check that the model is supported by the AOS 8 release in use.
4. Network: a managed switch with a few VLANs (management, users, guest), a DHCP server on which option 43 can be set, and a RADIUS server — FreeRADIUS, Windows NPS or a ClearPass evaluation VM — for 802.1X.
5. Virtual switching: the controller VM’s vNICs must allow VLAN trunks, and on VMware the port group needs promiscuous mode and forged transmits enabled so that user MAC addresses can pass.

A standalone Instant AP alone is an even cheaper starting point for learning roles, 802.1X and RF, and the Instant web UI makes many concepts in this series visible.

Common Misconceptions

• “The Mobility Conductor is a big controller.” It is not. APs never terminate on it and it carries no user traffic.
• “If the Conductor fails, Wi-Fi goes down.” Controllers keep running their committed configuration; only management and centralized services stop.
• “AP switchports need every user VLAN.” Not in tunnel mode — only the AP management VLAN. User VLANs live on the controller.
• “Instant and Instant On are the same.” Different product lines with different management and feature sets.
• “AOS 10 is just AOS 8.x plus one.” AOS 10 is a different architecture, managed only from Central.
• “VLANs define access.” In Aruba, roles define access; VLANs are just one attribute a role can carry.

Exercises

1. A hospital runs AOS 8 with a redundant Mobility Conductor pair and two four-node controller clusters. A data-centre power event takes both Conductors offline for two hours. Describe what clinicians on Wi-Fi experience and what the network team cannot do during that window.

Show answer

Clinicians notice nothing. APs remain connected to their controllers, users keep authenticating against RADIUS (the controllers are the RADIUS clients, not the Conductor) and traffic keeps flowing with the last committed configuration. The network team cannot push configuration changes, onboard new controllers, reassign licences, or see the centralized dashboard. AirMatch cannot compute a new RF plan and Conductor-based ClientMatch steering pauses, so RF slowly drifts from optimal until the Conductors return.

2. An engineer moves an employee SSID from tunnel to bridge forwarding mode without touching the switches. Clients associate but never receive an IP address. Why?

Show answer

In tunnel mode the user VLAN only needs to exist on the controller’s uplinks; the AP switchports carry only the AP management VLAN. In bridge mode the AP drops user traffic onto its own switchport, tagged with the WLAN’s VLAN. That VLAN is not allowed on the AP-facing access/trunk ports, so DHCP requests never reach a server. The fix is to trunk the user VLAN to every AP port (or use the AP’s native VLAN for users).

3. Match each requirement to Instant, AOS 8 controller-based, or AOS 10: (a) 40 coffee shops with three APs each and no on-site IT; (b) a defence contractor whose network may not depend on any cloud service; (c) a 300-site retailer that wants cloud management but must tunnel point-of-sale traffic to a central firewall at each regional hub.

Show answer

(a) Instant (or Instant On), managed from Central if central visibility is wanted. (b) AOS 8 with an on-premises Mobility Conductor — AOS 10 requires Central. (c) AOS 10: APs managed from Central, with gateways at the regional hubs and a tunnelled or mixed-mode SSID for point-of-sale devices.

4. In classic AOS 8 tunnel mode, could a packet capture taken on the AP’s switchport reveal a user’s HTTP request in clear text? What about in decrypt-tunnel mode?

Show answer

In tunnel mode, no: the GRE payload is the original 802.11 frame, still CCMP/GCMP-encrypted, because decryption happens on the controller. In decrypt-tunnel mode the AP decrypts first and sends 802.3 frames in GRE, so the HTTP request (though not HTTPS content) would be visible on the wire between AP and controller unless the tunnel is additionally protected.

5. Explain in two sentences why Aruba’s approach is called “user-centric”.

Show answer

Policy is attached to the authenticated user or device through a role, rather than to the port, SSID or VLAN the traffic arrives on. The same role — and therefore the same firewall rules, bandwidth limits and VLAN — follows the user wherever they connect.

Summary

Aruba’s wireless portfolio comes in three architectures. Instant elects a virtual controller from among the APs and bridges traffic locally. AOS 8 separates the management plane (the Mobility Conductor, formerly Mobility Master) from the control and data planes (Mobility Controllers), adding clustering, AirMatch, centralized licensing and Live Upgrade. AOS 10 moves management to Aruba Central, makes APs self-sufficient, and keeps gateways only for tunnelled traffic. In all of them the forwarding mode decides where encryption ends and where traffic exits, and every client is governed by a user role rather than by the port it arrived on.

Next: Part 2 builds the AOS 8 management layer — Conductor and controller models, the configuration hierarchy, the managed-device setup dialog, Conductor redundancy and licence pools.