HPE Aruba AOS-CX Getting Started: Central Onboarding

AOS-CX is the modern operating system that runs across the HPE Aruba Networking switching family — 6300, 6400, 8100, 8320, 8360, 8400, 9300 and the rest — and it is designed to be managed from Aruba Central from the moment it is powered on. Because the platform supports zero-touch provisioning (ZTP), a factory-default switch can reach the cloud, authenticate itself, receive a configuration and appear in your inventory without anyone attaching a console cable. This guide walks through the onboarding workflow based on the official HPE Aruba Networking getting-started documentation: how factory-default and pre-configured devices join Central, how template groups and UI groups differ, how to replace a VSX member, and which monitoring and troubleshooting tools you get once the device is managed.

What Aruba Central Adds to an AOS-CX Switch

Aruba Central is a cloud management service. Onboarding a switch turns it into a device that Central can monitor, configure and act on, and it changes the operating model in three useful ways:

• Inventory and health in one place. Every switch reports its operational state, neighbour topology and health score, so a rollout across many sites does not depend on per-site logins.
• Configuration as a group object. Instead of pasting CLI into twenty terminals, you define a group — with either CLI templates or UI settings — and every device that joins the group inherits the same intent.
• Remote operations. Reboots, tech support dumps, console access and stacking conductor handovers all become cloud actions on a managed switch.

Management in Central does not remove local access, but it does change who owns the configuration. That distinction matters later in this article.

Two Ways a Switch Reaches Central

There are two onboarding paths. Which one applies depends on whether the switch left the factory with a configuration or was already provisioned locally.

Factory-Default Devices (ZTP)

A new AOS-CX switch boots without a configuration. It brings up its management interface, obtains an address from DHCP, and contacts HPE Aruba Networking Activate to fetch its provisioning parameters. Once the device identifies Central as its management entity, it establishes the cloud connection on its own. Two conditions must be met on the Central side before this can succeed:

• The device must be in the Central device inventory. This is normally handled by the order-to-inventory sync or a manual Add Device using the serial number and MAC address.
• A valid subscription must be assigned to the device. An unsubscribed device may connect and then fail to be managed.

ZTP also assumes working DNS and outbound reachability. If the management network only allows filtered egress, allow the traffic required to reach Activate and Central, and consider a proxy configuration on the switch if one is required. In a lab you can skip the cloud round trip entirely with a local provisioning service, but that is a different workflow from Central onboarding.

Pre-Configured or Locally Managed Devices

A switch that has already been configured locally — through the console, SSH or a USB-based initial configuration — does not need Activate. The Central management service is enabled by default on AOS-CX, so once the device boots and can resolve and reach Central, it connects and registers itself. The same two conditions apply: the serial number must be in the inventory, and the device must have an assigned subscription.

Where the device has been staged on the bench, expect the first hello to Central before it is racked. If you want to control when that happens, leave the management interface isolated until the device is in place, then allow egress.

Before You Start: A Short Checklist

Onboarding a Factory-Default Switch

With the inventory and subscription in place, onboarding is mostly a matter of letting the switch do the work:

1. Rack and cable the switch, connect the management interface to the management VLAN, and apply power.
2. Confirm the device received an address from DHCP and can resolve external names.
3. Watch the device appear in Central. Devices pending onboarding show up first, then move to managed once the subscription and group assignment are valid.
4. From the switch console or SSH, verify the cloud connection state and the ZTP status. Depending on the AOS-CX release, the relevant commands are variants of:

switch# show ztp information
switch# show aruba-central
switch# show aruba-central status

If the device reports a connection but never reaches the managed state, the audit trail in Central is the fastest place to find out why — see the troubleshooting section below.

Onboarding a Pre-Configured Switch

When a switch already has a local configuration, the workflow is the same except that you may want to control the cloud-management settings explicitly. The AOS-CX CLI groups them under the Central context:

switch(config)# aruba-central
switch(config-aruba-central)# enable
switch(config-aruba-central)# activate
switch(config-aruba-central)# location Building-A
switch(config-aruba-central)# exit
switch# show aruba-central

Command syntax varies slightly between AOS-CX versions, so confirm the exact keywords against your release before scripting it. Before you go to production, revisit our HPE Aruba AOS-CX initial configuration guide so the management VLAN, hostname and time source are already correct.

Configuration Management: Template Groups vs UI Groups

Central gives you two ways to define a group's configuration, and the choice affects how you onboard devices later.

• Template groups. The configuration is delivered as CLI templates, with variables that let one template serve many devices. This suits environments where devices differ only in addresses and names, and it scales well across sites. Two practical traps: in templates, # starts a comment, so banner motd must use another delimiter such as @ or the banner is silently dropped; and variables must be defined for every device that joins the group.
• UI groups. Configuration is expressed through Central's UI options rather than raw CLI. This is friendlier for teams that do not want to maintain CLI templates, and it supports MultiEdit for bulk edits across devices plus a comparison against the running configuration.

Mixing both approaches in one group is not possible; pick the model that matches how your team maintains intent, and keep device models similar within a group so that UI options and templates apply cleanly.

Central Managed Mode and Configuration Lockout

In Central Managed mode the cloud becomes the single source of truth for configuration. Other interfaces — the local CLI, the REST API and SNMP writes — can no longer change the configuration, which prevents drift and stops two operators from overwriting each other.

One consequence is worth knowing before a migration: if a device has been configured with configuration-lockout central managed, moving it between groups will not rewrite its configuration. The lockout is doing its job, but it also means the new group's intent is not applied. Check the configuration status page for pending changes and any local overrides before assuming a group change took effect.

Replacing a VSX Member

Replacing a failed switch in a VSX pair is an onboarding task, not a CLI task: the replacement must land in exactly the same group as the device it replaces, otherwise it will never receive the same configuration.

• Template group: the new device must be onboarded with identical variable values. Reuse the previous device's variable set rather than typing them again.
• UI group: open the configuration in the MultiEdit configuration editor, copy the existing device's settings, and paste them onto the new device so both are driven by the same intent.

Once the replacement is managed and in sync, verify that the VSX pair reformed correctly — roles, ISL and MC-LAG state — using the checks in our ArubaOS-CX VSX configuration guide.

Monitoring and Troubleshooting a Managed Switch

After onboarding, the switch monitoring page is the default working view: operational status, topology map and health score, plus the detail views for interfaces, VLANs and power.

The Actions menu is where remote operations live:

• Reboot the device remotely.
• Generate a tech support dump for support cases.
• Open a remote console session (delivered over SSH, port 443).
• Switch the stacking conductor to another member during a maintenance window.

When onboarding fails, start with the audit trail. A successful sequence shows an onboarded event carrying the device serial number, followed by configuration push events and a successful login. Seeing the device connect but no onboarded event usually points at the subscription or inventory, while an onboarded event followed by failed pushes points at the group's configuration. The configuration status page complements this: look for pending changes and local overrides that explain why the device is not matching group intent.

Common Onboarding Failures

Scaling Onboarding Across Many Sites

The mechanics above work for one switch; they work for two hundred if you make three decisions early. Standardise on a single firmware family so templates stay valid. Build one group per hardware model and role rather than per site, and let variables carry the site-specific values. Finally, treat the group definition as code: review changes to templates the way you would review a firewall rule, because a bad template pushed to a group is a bad configuration on every device in it.

For wider context on how these switches fit into a data centre topology, see Spine-Leaf Architecture: Modern Data Center Topology, and for a programmatic alternative to templates, our guide to Ansible for network engineers shows how the same intent can be kept in version control.

Related Reading

• HPE Aruba AOS-CX Initial Configuration Guide (6300/6400)
• ArubaOS-CX VSX Configuration: Active-Active Switch HA
• ArubaOS-CX NAE: Scripts, Agents and Alerting
• AOS-CX Packet Capture: tcpdump on Aruba CX Switches

原文链接：https://arubanetworking.hpe.com/techdocs/central/latest/content/nms/aos-cx/get-started/quick-start-switch-cx.htm