11.1 Aruba Central Cloud Architecture and Group Configuration

Aruba Central Cloud Architecture and Group Configuration

Quick Summary: Aruba Central serves as the cloud-native single pane of glass for enterprise campus networking, unifying the provisioning, management, monitoring, and optimization of Aruba CX switches, Aruba wireless access points, and SD-Branch gateways. Infrastructure in Central is organized along three core constructs: Groups (configuration boundaries), Sites (physical/geographic locations for health monitoring), and Labels (informational tags for filtering). Administrators provision devices using either guided UI Groups or programmatic Template Groups backed by variable files, governed by Foundation or Advanced device subscription licenses.

---

The Cloud-Native Architecture of Aruba Central

Traditional enterprise network management relied on siloed, monolithic software applications installed on physical servers or virtual appliances. In contrast, Aruba Central is engineered as a cloud-native platform based on a modern microservices architecture running in public cloud data centers worldwide.

Key architectural pillars include:

• Microservices and Containerization: Discrete network management services—such as device configuration, firmware updates, client monitoring, telemetry ingestion, and AI processing—run as independently scalable containers. If one microservice undergoes maintenance or updates, the remainder of the platform operates without interruption.
• Multi-Tenant Public Cloud: The primary deployment model is a multi-tenant SaaS architecture where multiple customer accounts share underlying cloud compute and storage resources while maintaining strict cryptographic and logical tenant data isolation.
• Managed Service Provider (MSP) Mode: Aruba Central supports a specialized multi-tenant hierarchy where service providers can manage hundreds of independent customer accounts from a consolidated portal, allocating token-based licenses dynamically.
• Aruba Central On-Premises: For organizations with stringent data sovereignty, air-gapped, or regulatory compliance mandates that forbid public cloud management, Aruba offers Central On-Premises delivered on dedicated server appliances.
• Unified Single Pane of Glass: Central provides end-to-end operational visibility across wired campus switches (AOS-CX and legacy AOS-S), wireless access points (AOS 8 and AOS 10), and branch routing gateways, eliminating disconnected management consoles.

---

The Central Organizational Hierarchy: Groups, Sites, and Labels

To manage enterprise campus networks at scale, Aruba Central divides administrative tasks into three distinct dimensions: configuration, location monitoring, and metadata filtering.

1. Groups (Configuration Containers)

A Group is the primary configuration boundary in Aruba Central. It defines the baseline policy, features, and network settings that apply to devices assigned to that group.

• Single Membership Rule: Every managed device must belong to exactly one Group at any given time. A switch or AP cannot reside in multiple groups simultaneously.
• Device Type Isolation: A Group contains separate configuration sections for each supported device family (Switches, Access Points, and Gateways). Settings applied to switches do not affect APs in the same group.
• Baseline Inheritance: All devices placed into a Group inherit the common baseline configuration assigned to that group (such as corporate VLANs, NTP servers, DNS settings, and AAA radius servers).
• Device-Level Overrides: While baseline configuration is inherited from the Group, administrators can apply device-specific overrides (such as individual switch port descriptions or interface IP addresses) without removing the switch from its assigned group.

2. Sites (Geographic and Physical Boundaries)

A Site represents a physical geographic location—such as a corporate headquarters, a regional branch office, a university residence hall, or an individual building.

• Monitoring and Alerting Focus: Sites do not govern device configuration. Instead, Sites aggregate operational telemetry, client counts, RF health scores, connectivity health, and alarm thresholds based on physical proximity.
• Floor Plans and VisualRF: Sites house building floor plans, CAD drawings, and visual RF heatmaps, showing exact AP placements and client density.
• Topology Mapping: Central generates dynamic Layer 2 and Layer 3 topology maps organized by Site, allowing administrators to visualize physical links between access switches, aggregation layers, and APs.
• Cardinality: A device can belong to at most one Site (or remain unassigned to any site).

3. Labels (Multi-Dimensional Tagging)

Labels provide flexible, multi-dimensional metadata tagging for filtering, searching, and dashboard reporting.

• Arbitrary Tagging: Administrators assign labels based on departmental ownership (e.g., Finance, Executive), operational role (e.g., IoT-Gateway, Point-of-Sale), or building tier (e.g., Floor-2-North).
• Multiple Memberships: Unlike Groups and Sites, a single device can carry multiple Labels simultaneously.
• Search and Reporting: Labels allow operators to generate reports or view dashboard widgets filtered across multiple groups and sites simultaneously.

These three constructs describe Classic Central.

The New Central Scope Model

The next-generation HPE Aruba Networking Central ("new Central") organizes configuration differently (HPE Aruba Networking Developer Hub, "Central Hierarchy"):

Each device also has a device function (for example Mobility AP, access switch, or gateway) that keeps incompatible profiles off the wrong device. Precedence runs Device > Device Group > Site > Site Collection > Global, so the most specific setting wins.

---

Configuration Modes: UI Groups vs. Template Groups

When creating a Group in Aruba Central, the administrator must choose the configuration mode for each device type (Switches and APs):

UI Groups (Graphical Workflow Mode)

In a UI Group, configuration is managed entirely through guided web graphical interfaces, drop-down menus, and modal dialogs.

• Streamlined Workflows: Ideal for standard campus access deployments, providing point-and-click wizards for VLAN creation, port access profiles, 802.1X security policies, and VSF stack setup.
• Consistency Enforcement: The graphical interface validates input parameters and prevents syntax errors before settings are pushed to devices.
• Device-Level UI Customization: Specific switch settings (such as port descriptions, interface PoE limits, and static IP addresses) can be modified directly on individual switches via device-level UI tabs while keeping global settings synchronized with the group.
• Target Audience: Organizations prioritizing standardized configuration, rapid rollout, and minimal reliance on command-line scripts.

Template Groups (CLI Scripting Mode)

In a Template Group, configuration is managed through raw text configuration templates containing CLI commands and embedded variable placeholders.

• Variable Placeholders: Templates use variables enclosed in percent signs, such as %hostname%, %mgmt_ip%, %default_gateway%, or %vlan_id%.
• Variable Files (.csv): To bind unique values to each switch, administrators upload a comma-separated values (.csv) spreadsheet. The variable file contains a row for each switch (identified by MAC address or Serial number) and columns corresponding to each defined variable.
• Full CLI Expressiveness: Template groups allow administrators to configure advanced AOS-CX features that may not yet be exposed in the UI group menus, such as complex OSPF multi-area routing, custom route-maps, BGP peerings, or granular VRF isolation.
• Target Audience: Highly automated environments, legacy CLI network teams, and complex campus networks requiring programmatic, repetitive deployment of hundreds of switches.

Critical Exam Rule: Within a single Aruba Central Group, a device family (such as AOS-CX switches) must be configured in either UI mode or Template mode. You cannot mix UI mode and Template mode for switches within the same group. APs and switches within the same group, however, can use different configuration modes (e.g., switches in Template mode, APs in UI mode).

---

Device Onboarding and Subscription Licensing

Before an Aruba CX switch or AP can be managed by Aruba Central, it must be added to the customer inventory and assigned a valid subscription license.

The Onboarding Workflow

1. GreenLake Workspace Creation: The enterprise establishes an account on the HPE GreenLake cloud platform, which hosts Aruba Central.
2. Device Claiming: Devices are added to the GreenLake Device Inventory by entering their Serial Number and MAC Address, or by importing an electronic purchase order via a Cloud Activation Key.
3. Application Assignment: Claimed hardware is assigned to the Aruba Central application within the GreenLake portal.
4. Subscription License Allocation: Each device must have an active subscription license attached. Unlicensed devices can communicate with Central for initial onboarding but cannot be configured or monitored.

Subscription Tiers

Central device subscriptions are sold in two tiers for APs, switches, and gateways:

Exactly which features require Advanced changes over time, so verify against HPE's current subscription documentation rather than memorizing a feature list. Switch subscriptions are also sold by switch class, so a subscription for an entry-level switch class does not cover a higher-end switch.

---

Configuration Synchronization and Audit Safeguards

When changes are committed in Aruba Central, the platform orchestrates updates to all managed devices through persistent, secure outbound WebSocket connections.

Synchronization States

Central displays the real-time configuration state of every device:

• In Sync: The running configuration on the local switch exactly matches the configuration generated by Central.
• Sync Pending: Central is compiling or pushing configuration changes to the device, or the device is processing an update.
• Error / Out of Sync: An error occurred during configuration deployment (e.g., syntax conflict, insufficient hardware resources, or local configuration lock). Central logs the failure in the audit trail.

Automatic Configuration Rollback

A primary concern in cloud-managed networking is accidental loss of management reachability. In Classic Central, if a configuration push causes an AOS-CX switch to lose its connection to Central, the auto-rollback mechanism restores the last known stable configuration, taking about 10 minutes to roll back and reconnect. After recovery, Central sets the device's Auto Commit state to Off so it does not push the same change again; review the change that caused the disconnect before turning Auto Commit back on.

Audit Trails and Multi-Admin Concurrency

Aruba Central maintains a comprehensive, tamper-evident audit log detailing every administrative action, user login, license modification, and configuration commit.

---

Common Exam Traps

• Confusing Groups with Sites: Remember that Groups dictate how devices are configured, whereas Sites dictate where devices are located and how their health is monitored. Never select an option suggesting that a switch is placed into a Site to receive its VLAN configuration.
• Group Membership Limits: In Classic Central a switch can belong to only one Group, and groups do not nest. In new Central, inheritance comes from the scope hierarchy (Global, Site Collection, Site, Device Group, Device) instead.
• Mixing UI and Template Modes: You cannot configure half of your access switches in UI mode and the other half in Template mode within the same Group. They must be split into separate Groups.