Architecting Network Automation: The Comprehensive Guide to HPE Aruba Networking and Ansible Integration

The intersection of software-defined networking and infrastructure-as-code has culminated in the strategic partnership between HPE Aruba Networking and the Ansible automation framework. Ansible, an open-source orchestration tool originally created by Ansible and subsequently maintained by Red Hat, serves as a critical engine for automating the lifecycle of network provisioning, configuration management, and application deployment. By leveraging an agentless architecture based on Python, Ansible eliminates the need for proprietary software installation on target network devices, instead relying on standardized communication protocols. Since becoming an official Ansible partner in 2019, HPE Aruba Networking has extended this ecosystem to support a wide array of products, specifically targeting AOS-CX and AOS-Switch operating systems, as well as the centralized management capabilities of Aruba Central. The implementation of these tools allows network engineers to transition from manual, error-prone Command Line Interface (CLI) interactions to a declarative model where the desired state of the network is defined in code and enforced systematically across the enterprise.

The Fundamental Architecture of the Ansible Ecosystem

To successfully deploy Aruba automation, one must first understand the structural requirements of the Ansible Engine. The core of the operation is the Control Node, which is a dedicated workstation running a Linux or MacOS environment. This node acts as the primary execution environment where the Ansible Engine is installed.

The Control Node serves three primary functions:
1. It provides the Command-Line Interface (CLI) through which the administrator executes playbooks and ad-hoc commands.
2. It acts as the visualization hub where execution results and operational logs are displayed.
3. It houses the essential Ansible modules and plugins, which are the underlying Python scripts responsible for establishing connections and translating YAML directives into device-specific configurations.

While many Ansible modules typically utilize Secure Shell (SSH) for target device communication, the Aruba-specific modules are designed to leverage the REST APIs embedded within the AOS-CX and AOS-Switch operating systems. This shift from SSH-based scraping to API-based interaction ensures higher reliability, faster execution, and a structured data exchange format.

Deep Dive into Aruba Central Ansible Integration

Aruba Central, as the cloud-based management plane, requires a specific automation approach. Unlike individual switches, the Ansible inventory for Central is typically modest because it targets the Central instance itself rather than every individual device managed by the cloud. The Central instance then propagates configurations down to the target hardware.

Technical Requirements for Classic Central

For environments utilizing Classic Central, specific software and firmware dependencies must be met to ensure stability and compatibility:

• Python Version: Python 2.7 or Python 3.5 and above.
• Ansible Version: Version 2.9.0 or later.
• Firmware Version: A minimum of Aruba Central firmware version 2.5.2.

Installation and Deployment of the Classic Central Collection

The modules for Classic Central are bundled into a specific collection designed for easy distribution. Installation is handled via the ansible-galaxy utility.

To install the collection, the following command is executed:

bash ansible-galaxy collection install arubanetworks.aruba_central

For enterprise-grade deployments utilizing the Ansible Automation Platform (AAP), the requirements must be formalized within a directory structure. A directory named collections/ must contain a requirements.yml file. This file allows the automation controller to resolve and install dependencies at runtime.

The requirements.yml file must contain the following specification:

yaml collections: - arubanetworks.aruba_central

Inventory Configuration for Aruba Central

The inventory for Aruba Central requires specific variables to authenticate and route API calls correctly. A critical component of this is the API access token, which is used for the ansible_httpapi_session_key. It is important to note that these tokens expire every two hours, and this expiration window is currently not configurable, necessitating a process for token renewal.

The mandatory inventory variables are detailed in the following table:

An example of a valid inventory configuration for a Central host is as follows:

```yaml
arubacentral ansiblehost=internal-apigw.central.arubanetworks.com ansibleconnection=httpapi ansiblenetworkos=arubacentral ansiblehttpapiusessl=True ansiblehttpapicentralaccesstoken=CnjDaXXxvnjrvJRwxxxxXXxxXXXXxxxx

all:
hosts:
central:
ansiblehost: internal-apigw.central.arubanetworks.com
ansibleconnection: httpapi
ansiblenetworkos: arubacentral
ansiblehttpapiusessl: True
ansiblehttpapicentralaccesstoken: CnjDaXXxvnjrvJRwxxxxXXxxXXXXxxxx
```

Mastering AOS-CX Automation and the arubanetworks.aoscx Collection

The AOS-CX Ansible collection provides platform-dependent configuration management modules tailored for the AOS-CX network operating system. This integration allows for granular control over Layer 2 and Layer 3 configurations through a standardized Python-based interface.

System Prerequisites and Firmware Dependencies

Before deploying the AOS-CX collection, the environment must satisfy these criteria:

• Python: Version 3 or later.
• Ansible: Version 2.9.0 or later.
• Firmware: Minimum supported AOS-CX firmware version 10.04.
• Pycurl: Required specifically when performing aoscx_firmware_upload operations on 4100i and 6100 platforms.

Device-Side Configuration

Ansible cannot communicate with an AOS-CX device via REST API unless the API services are explicitly enabled. The following commands must be executed on the switch:

bash switch(config)# https-server rest access-mode read-write switch(config)# https-server vrf mgmt

The first command enables the REST API and grants read-write permissions, while the second command ensures the HTTPS server is listening on the management VRF, which is the standard path for out-of-band management.

Installation via Ansible Galaxy

The collection is installed using the Galaxy CLI. The process involves downloading the tarball and placing it into the local Ansible collections directory.

bash ansible-galaxy collection install arubanetworks.aoscx

Upon execution, the system will process the dependency map and install the collection (e.g., version 3.0.1) into the .ansible/collections/ansible_collections/arubanetworks/aoscx path.

Advanced Connectivity Strategies for AOS-CX

A significant architectural challenge in network automation is the coexistence of different communication methods. AOS-CX supports both REST API and SSH/CLI interactions. However, Ansible cannot mix these methods within a single play.

The "Separate Play" Requirement

If a playbook requires both REST API modules and SSH/CLI modules for the same host, they must be partitioned into separate plays. A single play cannot mix and match these calls.

• For REST API modules, the ansible_connection must be set to arubanetworks.aoscx.aoscx or httpapi.
• For SSH/CLI modules, the ansible_connection must be set to network_cli.

The recommended operational strategy is to set the default host variables to use the REST API and then override the ansible_connection to network_cli only within the specific plays that require SSH access.

REST API Implementation Methods: pyaoscx vs. Legacy

HPE Aruba Networking has transitioned its REST API implementation to utilize the pyaoscx Python SDK. This modernization improves performance and reliability.

The transition impact is as follows:
1. Legacy implementations continue to function but are no longer supported for new modules.
2. Users must install the pyaoscx package via pip:

bash pip3 install pyaoscx

3. The Ansible inventory should be updated to specify ansible_network_os=arubanetworks.aoscx.aoscx. The collection will automatically detect the presence of pyaoscx and utilize the modern connection method.

Detailed Inventory Variable Configurations

Depending on the connection method chosen, the inventory variables vary.

Method 1: pyaoscx Connection

This is the current recommended method for REST API interaction.

• ansible_connection: arubanetworks.aoscx.aoscx
• ansible_aoscx_validate_certs: False (or True if using signed certificates)
• ansible_aoscx_use_proxy: True or False (determines if the connection should bypass environment proxies)
• ansible_acx_no_proxy: True (specific to proxy bypass)

Example:
yaml aoscx_1 ansible_host=10.0.0.1 ansible_user=admin ansible_password=password ansible_network_os=arubanetworks.aoscx.aoscx ansible_connection=arubanetworks.aoscx.aoscx ansible_aoscx_validate_certs=False ansible_aoscx_use_proxy=False ansible_acx_no_proxy=True

Method 2: httpapi Connection

This is the standard REST API connection method.

• ansible_connection: httpapi
• ansible_httpapi_validate_certs: False
• ansible_httpapi_use_ssl: True
• ansible_acx_no_proxy: True

Example:
yaml aoscx_1 ansible_host=10.0.0.1 ansible_user=admin ansible_password=password ansible_network_os=arubanetworks.aoscx.aoscx ansible_connection=httpapi ansible_httpapi_validate_certs=False ansible_httpapi_use_ssl=True ansible_acx_no_proxy=True

Method 3: network_cli Connection

This method utilizes SSH for traditional CLI-based automation.

• ansible_connection: network_cli

Example:
yaml aoscx_1 ansible_host=10.0.0.1 ansible_user=admin ansible_password=password ansible_network_os=arubanetworks.aoscx.aoscx ansible_connection=network_cli

Practical Application: Configuring L3 Interfaces

To implement a configuration change, such as creating a Layer 3 interface, the playbook must explicitly reference the arubanetworks.aoscx collection.

The following example demonstrates the creation of an L3 interface with both IPv4 and IPv6 addresses:

yaml - hosts: all collections: - arubanetworks.aoscx vars: ansible_python_interpreter: /usr/bin/python3 gather_facts: False tasks: - name: Create L3 Interface 1/1/3 aoscx_l3_interface: interface: 1/1/3 description: Uplink_Interface ipv4: - 10.20.1.3/24 ipv6: - 2000:db8::1234/64

In this configuration, gather_facts: False is often used to speed up execution by skipping the automatic discovery of system information, which is frequently unnecessary for direct interface configuration tasks.

Conclusion

The integration of Ansible with HPE Aruba Networking's ecosystem represents a significant leap in network operational efficiency. By utilizing the arubanetworks.aruba_central and arubanetworks.aoscx collections, organizations can move away from the fragility of manual configuration and toward a robust, version-controlled infrastructure. The transition to the pyaoscx SDK highlights a commitment to modernizing the API interaction layer, providing more stable and scalable automation. Success in this environment requires strict adherence to the "Separate Play" rule when mixing REST API and SSH connections and a precise configuration of inventory variables to ensure seamless authentication and communication. As the network grows, the use of a dedicated Linux-based Control Node and the strategic use of the Ansible Automation Platform's requirements.yml file ensures that these automations remain portable, reproducible, and maintainable across the enterprise.

Sources

1. Ansible Getting Started - Aruba Central
2. Getting Started with Ansible and AOS-CX
3. AOS-CX Ansible Collection GitHub