7.1 AOS 10 Architecture and Aruba Central Integration
Key Takeaways
AOS 10 eliminates dedicated on-premises Mobility Conductors (formerly Mobility Masters), shifting all control, management, and orchestration intelligence into Aruba Central cloud microservices.
Aruba Central functions as a unified cloud-native platform providing AI-driven telemetry, automated configuration management, and centralized policy orchestration across campus APs, switches, and gateways.
Devices are onboarded by adding them to an HPE GreenLake workspace, assigning them to Central with a subscription, and letting zero-touch provisioning through Activate redirect them to Central over outbound HTTPS.
In AOS 10 the Key Management Service (KMS) in Central distributes PMK or 802.11r R1 keys and station records to the neighbor APs that AirMatch identifies, enabling fast roaming without a controller.
AOS 10 unifies AP software across campus and branch architectures into a single binary image, eliminating the legacy division between Campus APs (CAPs) and Instant APs (IAPs).
AOS 10 Architecture and Aruba Central Integration
Quick Summary: ArubaOS 10 (AOS 10) represents a fundamental architectural evolution in enterprise wireless networking. By decoupling network management and control plane functions from on-premises hardware and embedding them into Aruba Central cloud microservices, AOS 10 eliminates the need for dedicated on-premises Mobility Conductors. Access points run a single unified software image, onboard automatically via Zero-Touch Provisioning (ZTP) through Aruba Activate, and rely on cloud services in Central (AirMatch, ClientMatch, and the Key Management Service) while user traffic continues to be forwarded locally or through gateways.
The Architectural Evolution: From AOS 8 to AOS 10
In legacy enterprise wireless deployments operating under ArubaOS 8 (AOS 8), networks were divided into two distinct operational models, each requiring separate hardware architectures, licensing schemes, and operating firmware binaries:
- Controller-Based Campus Networks (Campus APs / CAPs): Access points functioned as lightweight radio heads that formed proprietary control and data tunnels back to centralized hardware appliances called Mobility Controllers (MCs). Network orchestration, radio management, and global configurations were governed by a dedicated physical or virtual appliance known as the Mobility Conductor (formerly Mobility Master). While this delivered centralized policy enforcement, it required costly on-premises redundancy appliances, complex licensing, and single points of architectural failure.
- Controllerless Distributed Networks (Instant APs / IAPs): Access points operated autonomously in localized virtual controller clusters. One IAP was elected as the Virtual Controller (VC) to manage neighboring APs within the same Layer 2 broadcast domain. While cost-effective for small branches, IAP clusters could not scale efficiently across large multi-building enterprise campuses and lacked unified policy enforcement.
The AOS 10 Paradigm Shift
AOS 10 converges these disparate models into a single, unified operating system architecture. In AOS 10, there is no separate IAP or CAP image; every Aruba access point runs the exact same firmware binary. The dedicated on-premises Mobility Conductor appliance is completely eliminated. Instead, Aruba Central serves as the unified, cloud-native control, management, and orchestration plane for all wireless access points, AOS-CX switches, and Aruba Gateways.
Aruba Central as the Cloud Control and Management Plane
Aruba Central is built on a modern, cloud-native microservices architecture deployed across globally distributed public cloud regions. Rather than relying on monolithic software stacks running on on-premises appliances, Central separates functions into independent, scalable microservices:
- Management Plane: Provides a single-pane-of-glass graphical user interface (GUI) and comprehensive REST APIs for configuration deployment, device provisioning, firmware lifecycle management, inventory tracking, and compliance auditing.
- Control Plane Microservices: Centralizes complex computational tasks that previously bogged down local controllers or individual APs. These cloud services include AirMatch (machine-learning radio frequency optimization), ClientMatch (real-time client steering analytics), AirSlice (application-level QoS slicing for SLA assurance), and AI Insights (continuous anomaly detection and automated root-cause analysis).
- Decoupled Data Plane: While Central manages control and configuration intelligence, user payload traffic (the data plane) is completely decoupled. Data traffic never traverses Aruba Central. Client frames are either switched directly onto the local access switch (Bridge mode) or encapsulated into tunnels terminating on local Aruba Gateways (Tunnel mode).
Cloud Elasticity and High Availability
Because the control plane operates in the cloud, enterprise networks gain automated scalability. An organization can expand from 10 APs in a single office to 50,000 APs across hundreds of global campuses without purchasing, sizing, or upgrading controller hardware appliances. Central automatically scales microservices to handle increased telemetry streams, configuration synchronization, and RF optimization calculations.
Aruba Central Configuration Hierarchy: Groups, Sites, and Labels
To manage enterprise scale effectively, Aruba Central organizes devices and administrative policies using a strict three-tier organizational hierarchy:
+-------------------------------------------------------------+
| Aruba Central |
+-------------------------------------------------------------+
|
+-----------------------+-----------------------+
| |
+---------------+ +---------------+
| Group "Corp" | | Group "Branch"|
| (Config) | | (Config) |
+---------------+ +---------------+
| |
[Pushes SSIDs, Radios, AAA] [Pushes SSIDs, Radios, AAA]
| |
+-----------------------+-----------------------+
|
+------------------+------------------+
| |
+---------------+ +---------------+
| Site: NY-HQ | | Site: Austin |
| (Physical Loc)| | (Physical Loc)|
+---------------+ +---------------+
| |
[Aggregates Telemetry, Health, Floorplans, Alarms]
| |
+----+----+ +----+----+
| | | |
Label: Label: Label: Label:
"Floor-1" "Exec" "Lab" "Warehouse"
1. Groups (The Configuration Container)
- A Group is the primary configuration container in Aruba Central. Devices placed inside a Group inherit that Group's common configuration settings, including WLAN SSIDs, RF profiles, VLAN mappings, AAA server configurations, and security policies.
- Mutual Exclusivity: An access point or switch can belong to one and only one Group at any given time.
- Device Type Segmentation: Within a Group, configurations are partitioned by device family (e.g., Access Points, AOS-CX Switches, Gateways), allowing administrators to configure holistic campus branch policies within a single container.
2. Sites (The Physical Location Container)
- A Site represents a physical geographic location, such as a campus building, branch office, hospital clinic, or warehouse facility.
- Sites are used exclusively for monitoring, operational health, and spatial context. They do not define device configurations.
- Devices in different Groups can be assigned to the same Site. For example, access points running a corporate campus configuration (Group "Campus-WLAN") and access switches running a standard access configuration (Group "Campus-Switches") are assigned to the same physical Site ("Chicago-Building-A").
- Sites enable location-based dashboards, VisualRF floor plans, contextual AI Insights, and physical topology mapping.
3. Labels (The Metadata Tag Container)
- Labels are flexible, tag-based organizational markers that can be applied to devices or clients regardless of their Group or Site assignments.
- Labels allow administrators to filter operational dashboards, generate targeted maintenance reports, or aggregate device subsets (e.g., "Executive-Boardroom", "Outdoor-Garden", "High-Density-Lecture-Hall").
- A single device can have multiple Labels applied simultaneously.
New Central: The Scope Hierarchy
HPE now also offers the next-generation HPE Aruba Networking Central (often called "new Central") alongside Classic Central. New Central replaces the mandatory group with a scope hierarchy: a Library of reusable profiles, then Global, Site Collection (optional), Site, Device Group (optional), and Device. Each device has a device function (for example Mobility AP, access switch, or gateway) that decides which profiles apply. Configuration is inherited downward and overridden upward: Device > Device Group > Site > Site Collection > Global. A device can belong to only one device group. Exam questions written for Classic Central still use groups and sites, so learn both models.
Device Onboarding: Zero-Touch Provisioning (ZTP) and Aruba Activate
A critical operational capability of AOS 10 is Zero-Touch Provisioning (ZTP). Network installers do not need to connect console cables, load initial configuration files via TFTP, or pre-stage access points in a lab. The onboarding process is completely automated via the Aruba Activate cloud redirection service:
+--------+ +-----------+ +----------------+ +---------------+
| New AP | | Local AP | | Aruba Activate | | Aruba Central |
| (Boot) | | Network | | Cloud Service | | Cloud Instance|
+--------+ +-----------+ +----------------+ +---------------+
| | | |
| 1. DHCP Request | | |
|-------------------->| | |
| 2. IP + DNS Assigned| | |
|<--------------------| | |
| | | |
| 3. HTTPS Connect (activate.arubanetworks.com) |
|--------------------------------------------->| |
| | 4. Validate Serial/MAC |
| | Match Customer Account |
| |---------------------------|
| 5. Return Central URL & Customer Token | |
|<---------------------------------------------| |
| |
| 6. Establish Secure TLS & WebSocket Connection (TCP 443) |
|------------------------------------------------------------------------->|
| |
| 7. Central Pushes Assigned Group Config, Firmware, and License |
|<-------------------------------------------------------------------------|
| |
| 8. AP Applies Config and Begins Broadcasting WLANs |
Step-by-Step ZTP Onboarding Workflow
- Inventory and Subscription (before installation): The device serial number and MAC address are added to the organization's HPE GreenLake workspace, the device is assigned to the Central service, and a subscription is applied (manually or by auto-subscribe). In Central, the device is pre-assigned to its group or site.
- Unboxing and Physical Uplink: The AP is mounted and plugged into a Power over Ethernet (PoE) switch port on an access switch.
- IP and DNS Acquisition: The AP boots into factory-default mode and broadcasts a DHCP request. It receives an IP address, subnet mask, default gateway, and DNS server address.
- Aruba Activate Interrogation: The AP resolves and contacts
activate.arubanetworks.comover a secure HTTPS session (TCP port 443). The AP transmits its factory-burned hardware MAC address, serial number, and TPM (Trusted Platform Module) certificate. - Inventory Matching & Redirect: Activate checks that the AP belongs to a customer inventory (populated from GreenLake) and returns the Central instance the device should use.
- Secure Cloud Connection: The AP contacts its assigned Central instance, opening an outbound TLS and WebSocket tunnel over TCP port 443. Because the connection is strictly outbound, campus firewalls do not require special inbound port forwarding rules.
- Configuration & Firmware Provisioning: Central places the AP in its designated group or scope, checks the assigned firmware compliance baseline (performing an automated image upgrade if needed), pushes the group configuration, and enables cloud telemetry streaming.
Fast Roaming in AOS 10: The Key Management Service (KMS)
AOS 10 has no controller holding everyone's keys and no "virtual controller" AP. Instead, the Key Management Service (KMS) in Central does that job (HPE Aruba Networking AOS 10 TechDocs, "Roaming and the key management service"):
- A client associates to AP1 and completes 802.1X. AP1 obtains the Pairwise Master Key (PMK), or the R0 key if 802.11r is enabled.
- AP1 sends the client's station record (PMK or R0 key, VLAN, user role, and machine-authentication state) to KMS.
- KMS asks AirMatch for AP1's list of neighbor APs. With 802.11r, KMS derives an R1 key for each neighbor (this step is skipped for Opportunistic Key Caching).
- KMS pushes the station record to the neighbors, so when the client roams to AP2, only the four-way key exchange is needed instead of a full 802.1X authentication.
- After the roam, AP2 tells KMS the client moved, KMS updates the next set of neighbors, and AP2 synchronizes the client's active sessions with AP1.
By default, 802.11r is enabled and OKC is disabled on AOS 10 WLANs. Enabling 802.11k also activates 802.11v in the background.
What Happens If Central Is Unreachable (Survivability)
Because several AOS 10 services live in Central, an outage has specific, predictable effects (AOS 10 TechDocs, "Survivability"):
| Area | Behavior during the outage |
|---|---|
| Client traffic | APs and gateways keep forwarding with their existing configuration and security policies |
| Authentication | No impact for local or centralized RADIUS if the server is still reachable; Central-hosted Cloud Authentication cannot admit new clients |
| Fast roaming | Existing clients can fast-roam to neighbors that already received their keys; new clients perform full (slow) authentication when they roam |
| ClientMatch | No steering until Central returns; clients still connect and roam |
| AirMatch | APs keep their current channel, width, and power, and still react to radar and high-noise events; no new plan is deployed |
| Configuration and ZTP | No configuration changes, and no new APs or gateways can be provisioned |
| Monitoring | Monitoring and event data for affected devices are lost for the outage period |
Architectural Comparison: AOS 8 vs AOS 10
| Architectural Attribute | AOS 8 Architecture | AOS 10 Architecture |
|---|---|---|
| Primary Control Appliance | On-premises Mobility Conductor (hardware or VM) | Cloud-native Aruba Central Microservices |
| AP Firmware Models | Split: Campus AP (CAP) vs Instant AP (IAP) | Single Unified AP firmware binary |
| Device Onboarding | Manual console staging, DHCP Option 43, or IAP VC | GreenLake inventory and subscription, then ZTP through Activate |
| RF Optimization Engine | Local Adaptive Radio Management (ARM) / AirMatch VM | Cloud-native AirMatch Machine Learning |
| Client Steering and Fast-Roaming Keys | ClientMatch and key caching on the Mobility Conductor/controllers | ClientMatch orchestrated by Central; keys distributed by KMS |
| Configuration Hierarchy | Mobility Conductor / Node Hierarchy folders | Classic Central groups, sites, and labels, or new Central scopes |
| Management-Plane Outage Impact | Depends on Conductor and controller reachability | Forwarding continues; configuration, ClientMatch, new AirMatch plans, KMS distribution, and monitoring pause |
Common Exam Traps
- The Mobility Conductor Trap: Believing that an AOS 10 enterprise campus requires an on-premises Mobility Conductor hardware appliance. In AOS 10, the Mobility Conductor is completely eliminated; Aruba Central handles all conductor responsibilities.
- Groups vs. Sites Confusion: In Classic Central, groups apply configuration (SSIDs, security, VLANs) and sites aggregate monitoring and location data (telemetry, floor plans, health). An AP belongs to one group, but devices from multiple groups can share a site. In new Central, sites are part of the configuration scope hierarchy.
- Cloud Outage Behavior: APs do not stop broadcasting SSIDs if Central becomes unreachable; they keep forwarding with their existing configuration. What stops is cloud-dependent work: configuration changes, ClientMatch steering, new AirMatch plans, key distribution for new clients, Cloud Authentication, and monitoring.
Which architectural shift represents a fundamental difference between legacy ArubaOS 8 (AOS 8) and modern ArubaOS 10 (AOS 10) in an enterprise wireless deployment?
AOS 10 requires every access point to operate as an autonomous standalone router with its own DHCP pool
AOS 10 removes the need for on-premises Mobility Conductors by moving management into Central
AOS 10 forces all wireless user traffic to be tunneled across the Internet to a cloud firewall for inspection
AOS 10 reintroduces separate, non-interchangeable firmware images for Campus APs and Instant APs
An enterprise network administrator is deploying 60 Aruba access points across two separate office buildings located in Chicago and Dallas. The administrator needs both offices to broadcast identical corporate WLAN configurations and security settings, while visualizing monitoring telemetry, floor plans, and health alerts independently for each physical building. How should the administrator organize these devices in Aruba Central?
Create separate Sites to distribute configuration and assign all APs to one Group for monitoring
Put all APs in one Group for the shared WLAN settings, and create two Sites for location monitoring
Assign all APs to one Site and create Labels for Chicago and Dallas that push separate SSIDs
Place the APs into two Groups, because Groups control both configuration and floor plan mapping
An AOS 10 campus uses bridge-mode SSIDs with 802.11r. The internet link to HPE Aruba Networking Central fails for an hour, while the on-premises RADIUS server stays reachable. Which outcome matches HPE's documented survivability behavior?
Clients are forced onto open authentication because RADIUS requests from APs must pass through Central
All APs stop broadcasting their SSIDs until the connection to Central is restored, then rejoin clients
An elected cluster-leader AP takes over key distribution and RF planning for the site until Central returns
Existing clients keep working and fast-roam to APs holding their keys; config changes and ClientMatch pause
Sections you finish are checked off in the contents.