Automation, Orchestration, and Infrastructure as Code
Three ways to reach AOS-CX
Every AOS-CX switch exposes the same intent through a CLI, a REST API, and SNMP or streaming telemetry. The REST API is the foundation: authenticate, obtain a session cookie or token, then GET/POST/PUT against versioned URIs. Automation tooling sits on top - Ansible collections, Python SDKs, NetEdit for guided multi-switch changes, Aruba Fabric Composer for EVPN/VXLAN and fabric-wide workflows, and Aruba Central for cloud management and templating.
Orchestration and IaC discipline
- Declarative over imperative: describe the desired state and let the tool reconcile; make tasks idempotent so a second run changes nothing.
- Version everything in Git; treat device configuration as code with peer review.
- Take a checkpoint before bulk changes and validate with post-change checks.
- Zero-touch provisioning: DHCP options point a new switch at its controller or image, it boots, checks in, receives a template, and is validated.
- Streaming telemetry (gNMI) and NAE scripts turn the fabric into a data source for the pipeline.
Traps
- Assuming a REST call is atomic - a partially applied change leaves the device in a state nobody tested.
- Hard-coded credentials instead of a secrets store, and ignoring API session/rate limits.
- Believing a CLI
nocommand maps one-to-one onto a REST DELETE; check the endpoint. - Re-running a playbook against changed inventory without diffing first.
- Automating a broken process faster.
Rule of thumb
Write the verification before the change: one command whose output proves the desired state (for example, a show command you can parse for the expected VNI-to-VLAN mapping). If you cannot state the check, do not automate the change.