Chapter 2: AOS-CX CLI, Configuration Management, and Initial Setup

The AOS-CX command-line interface (CLI) will feel familiar to anyone who has worked with Cisco IOS, Juniper Junos, or HPE's older ProVision/Comware operating systems — but it has its own personality. Aruba designed it to be modern, predictable, and tightly integrated with the underlying database-driven architecture you learned about in Chapter 1.

Operator, Manager, and Configuration Modes

AOS-CX organizes commands into three primary modes, each with its own level of privilege and its own prompt character. You can think of these modes like the floors of a secure office building: the lobby is open to anyone with a badge, the staff floor requires elevated credentials, and the executive suite is locked behind another layer of access.

A subtle but important detail: AOS-CX uses configure (or configure terminal) to enter global configuration mode. Both forms work, but configure alone is the documented Aruba shorthand.

switch> enable
switch# configure
switch(config)# interface 1/1/1
switch(config-if)# exit
switch(config)# end
switch#

The end command is your express elevator: from any depth of sub-configuration, end jumps you all the way back to Manager mode. exit only goes up one level. This distinction will save you from the embarrassment of typing exit six times to escape a deeply nested ACL.

Figure 2.1: AOS-CX CLI mode hierarchy and transitions

Context-Sensitive Help and Command Completion

AOS-CX has one of the most forgiving help systems in the industry. There are three tricks to memorize, and they will carry you through the entire exam:

1. Question mark (?) — Lists every command or argument valid at the current cursor position.
2. Tab key — Auto-completes a partially typed command, or shows options if multiple commands match.
3. Partial commands — As long as your input is unambiguous, AOS-CX accepts shortened keywords (int 1/1/1 for interface 1/1/1).

switch(config)# in?
include-credentials  interface  ip
switch(config)# inter<TAB>
switch(config)# interface

Command Piping and Filtering

AOS-CX supports Unix-style pipes to filter and format output:

CLI Sessions, Aliases, and Banners

AOS-CX allows multiple concurrent CLI sessions and supports both aliases (custom shorthand commands) and banners (login messages). Banners are not just decorative — many regulatory frameworks (PCI-DSS, HIPAA) require a legal warning banner on management interfaces.

switch(config)# alias shrun show running-config
switch(config)# alias shint show interface brief
switch(config)# banner motd #
Authorized access only. All activity is logged.
#

A factory-default Aruba CX switch ships with no IP address, no users, and SSH disabled. The very first thing you do with one is connect to the console — and that workflow is the same whether you bought a 6300 stack for an IDF closet or an 8400 chassis for a data-center spine.

Console and Out-of-Band Management (OOBM)

Every CX switch has at least two ways to reach it before the network is configured:

1. Console port — A serial connection (RJ-45 or USB-C on newer models) at 9600 baud, 8N1, no flow control. This is your "always works" lifeline.
2. OOBM port — A dedicated 1 GbE management interface on the front panel, typically labeled mgmt. It lives in its own dedicated VRF, isolated from production traffic.

The OOBM interface is configured under interface mgmt, and uniquely uses the command ip static rather than ip address. This is one of the most common gotchas for engineers crossing over from Cisco or older Aruba ProVision platforms.

switch(config)# interface mgmt
switch(config-if-mgmt)# no shutdown
switch(config-if-mgmt)# ip static 192.168.50.201/24
switch(config-if-mgmt)# default-gateway 192.168.50.1
switch(config-if-mgmt)# exit

Note that the default gateway is configured inside the interface mgmt context, not at the global level — another departure from traditional CLIs.

Hostname, Domain, and DNS

The hostname is set globally, while DNS settings must specify the management VRF if your name servers are reachable only through OOBM:

switch(config)# hostname ACCESS-IDF1-SW01
ACCESS-IDF1-SW01(config)# ip dns server-address 192.168.50.10 vrf mgmt
ACCESS-IDF1-SW01(config)# ip dns domain-name corp.example.com vrf mgmt
ACCESS-IDF1-SW01(config)# ntp server pool.ntp.org vrf mgmt

If you forget the vrf mgmt keyword, AOS-CX will configure DNS for the default VRF (data plane), which usually has no path to your management subnet, leaving you wondering why name resolution silently fails.

Local User Accounts and RBAC

AOS-CX ships with a single default admin account whose password must be set on first login. AOS-CX supports up to 29 user-defined groups in addition to the predefined ones.

ACCESS-IDF1-SW01(config)# user netadmin group administrators password plaintext H@rdPass!1
ACCESS-IDF1-SW01(config)# user helpdesk group operators password plaintext View0nly!

Worked Example — Creating a Custom Role:

switch(config)# role vlan-only
switch(config-role)# rule 10 permit config command "vlan*"
switch(config-role)# rule 20 permit exec command "show*"
switch(config-role)# exit
switch(config)# user vlan-jr group operators password plaintext Vlan0nly!

Enabling SSH and Disabling Telnet

By default, SSH is enabled on the management VRF and Telnet is disabled. Verifying and adjusting these settings is a routine hardening task:

ACCESS-IDF1-SW01(config)# ssh server vrf mgmt
ACCESS-IDF1-SW01(config)# ssh server vrf default
ACCESS-IDF1-SW01(config)# no telnet-server vrf mgmt
ACCESS-IDF1-SW01# show ssh server vrf mgmt

For tighter security, apply a control-plane ACL that only permits SSH from your jump-host subnet:

switch(config)# access-list ip MGMT-ACL
switch(config-acl-ip)# 10 permit tcp 10.10.10.0/24 any eq 22
switch(config-acl-ip)# 40 deny tcp any any eq 22
switch(config-acl-ip)# 50 permit any any any
switch(config-acl-ip)# exit
switch(config)# apply access-list ip MGMT-ACL control-plane vrf mgmt

If initial setup is the blueprint, configuration management is the version-control system. AOS-CX has a richer model than many competing platforms, blending the familiar running-config / startup-config pair with a powerful checkpoint system that acts like a built-in time machine.

Running vs. Startup Configuration

The running-config lives in RAM and reflects every change as it is typed. The startup-config lives in flash and is loaded on boot. Changes made in config mode do not persist across reboots until you save them.

To save the running-config to startup-config, AOS-CX gives you two equivalent commands — write memory and the shorter save:

ACCESS-IDF1-SW01# write memory
ACCESS-IDF1-SW01# save

Checkpoints: Snapshots Beyond Startup-Config

A checkpoint is a named, point-in-time snapshot of the running-config — independent of startup. You can create as many as you like, name them meaningfully, and roll back to any one instantly.

switch# copy running-config checkpoint pre-vlan-change
switch# show checkpoints
switch# show checkpoint pre-vlan-change
switch# rollback checkpoint pre-vlan-change

AOS-CX also generates automatic checkpoints, named with a timestamp prefix like CPC202604291843. By default, the system creates one roughly five minutes after the last config change if you have not saved.

Figure 2.2: Configuration management workflow across running, startup, and checkpoint stores

Auto-Checkpoint on Commit (Safe Testing)

The most powerful — and exam-favored — feature is checkpoint auto, which arms a deadman timer between 1 and 60 minutes. If you don't confirm your changes before the timer expires, the switch automatically rolls back to the pre-change state.

switch# checkpoint auto 5
switch# configure
switch(config)# router ospf 1
switch(config-ospf-1)# area 0
switch(config-ospf-1)# exit
switch(config)# end
switch# show ip ospf neighbor
... (verify connectivity)
switch# checkpoint confirm

If, after starting checkpoint auto 5, you fat-finger a command that severs your SSH session, the switch waits five minutes, hears no checkpoint confirm, and rolls back automatically. Five minutes later you are back in.

Copying Configurations: TFTP, SFTP, and USB

switch# copy running-config tftp://192.168.50.20/sw01-backup.cfg vrf mgmt
switch# copy startup-config sftp://backup@192.168.50.20/configs/sw01.cfg vrf mgmt
switch# copy tftp://192.168.50.20/sw01-restore.cfg running-config vrf mgmt
switch# copy usb:sw01.cfg running-config

When something breaks at 2 a.m., your job isn't to remember every command — it's to know where the truth lives. AOS-CX consolidates diagnostic information into a small set of go-to commands that any new engineer should rehearse before they ever need them in anger.

show tech-support and Core Dumps

show tech-support is the kitchen-sink diagnostic dump. It runs hundreds of show commands and concatenates the output into a single file you can hand to TAC.

switch# show tech-support
switch# show tech-support local-file
switch# copy show-tech tftp://192.168.50.20/sw01-tech.txt vrf mgmt

For deeper failures, AOS-CX stores core dumps — memory snapshots of crashed processes:

switch# show core-dump
switch# copy core-dump <id> tftp://192.168.50.20/ vrf mgmt

Event Logs and Severity Levels

The event log is structured and severity-tagged — much friendlier to grep than a free-form syslog stream:

switch# show events
switch# show events -d ospfd
switch# show events -s warning
switch# show events | include link

Debug Commands

AOS-CX has per-feature debugging that you can toggle live without affecting other modules. Unlike older OSes where debug all could melt the CPU, CX debugging is daemon-scoped:

switch# debug ospfv2 all
switch# debug bgp updates
switch# show debug
switch# no debug ospfv2 all
switch# no debug all

Syslog Forwarding

For long-term retention and central correlation, forward events to an external syslog server. AOS-CX supports UDP (514), TCP (1470), and TLS (6514) targets:

switch(config)# logging 192.168.50.30 vrf mgmt severity info
switch(config)# logging 192.168.50.30 vrf mgmt udp 514 severity info
switch(config)# logging 192.168.50.30 vrf mgmt tls 6514 severity warning

Figure 2.3: Compliance-grade syslog forwarding flow over TLS