Mastering Network Automation with Ansible for HPE Aruba Networking

The integration of Ansible into the HPE Aruba Networking ecosystem represents a paradigm shift from manual, CLI-driven device management to a scalable, programmable infrastructure. Ansible, an open-source automation framework originally created by Ansible and currently maintained by Red Hat, serves as a sophisticated orchestration tool. Its primary function is to automate the critical lifecycle phases of network operations, specifically provisioning, configuration management, and the deployment of applications. By leveraging a declarative approach, Ansible allows network engineers to define the desired state of their infrastructure, which the Ansible Engine then implements across target devices.

In 2019, HPE Aruba Networking formalized this relationship by becoming an official Ansible partner. This partnership ensures that the automation framework is deeply integrated with Aruba's hardware and software offerings, providing official support for the AOS-Switch and AOS-CX operating systems, as well as the Classic Central management platform. The fundamental architecture of Ansible is agentless, meaning it does not require the installation of proprietary software on the target switches or controllers. Instead, it relies on a "control node," which is a Linux or MacOS workstation where the Ansible Engine is installed. This control node acts as the central nervous system, providing the command-line interface (CLI) for execution and housing the Python-based modules and plugins necessary to communicate with Aruba devices.

Core Architectural Requirements and the Control Node

The effectiveness of an Aruba automation strategy depends on the correct configuration of the Ansible control node. Because Ansible is architected on Python, the control node must be a compatible environment capable of executing Python code.

Hardware and Operating System Specifications

The control node is essentially a Linux machine, although MacOS is also supported. This environment is where the Ansible Engine resides. The engine provides the essential interface for executing commands and displaying the results of playbooks. Without a properly configured control node, the automation of AOS-CX or Aruba Central is impossible, as the engine contains the logic required to translate YAML playbooks into API calls or SSH commands.

Software Dependency Matrix

Depending on the specific Aruba product being managed, the software requirements vary. For those utilizing the Classic Central collection, the following specifications are mandatory:

Deployment of Aruba-Specific Ansible Collections

To interact with Aruba hardware and software, general Ansible installation is insufficient; specific collections must be deployed. Collections are bundles of modules and plugins that provide the specialized logic needed to communicate with Aruba's unique APIs and CLI structures.

Installation via Ansible Galaxy

The standard method for acquiring these tools is through ansible-galaxy. For Classic Central, the specific command for installation is:

ansible-galaxy collection install arubanetworks.aruba_central

Similarly, for AOS-CX environments, the arubanetworks.aoscx collection must be installed. After the installation process is complete via the ansible-galaxy command, the user should navigate into the collections directory where the arubanetworks.aoscx files were placed to verify the installation.

Integration with Ansible Automation Platform

For enterprises utilizing the Ansible Automation Platform (AAP), the installation process involves a more structured approach using a requirements.yml file. This file must be placed within a directory labeled collections/. The Automation Controller uses this file to identify and install dependencies at runtime. For Classic Central, the collections/requirements.yml file must contain the following structure:

yaml collections: - arubanetworks.aruba_central

AOS-CX Automation: Communication Methods and Modules

The AOS-CX Ansible Collection provides a dual-path communication strategy, utilizing both the REST API and the Command Line Interface (CLI) via SSH. This flexibility allows administrators to choose the most efficient method for a given task.

REST API and the Pyaoscx Evolution

Modern AOS-CX modules leverage REST APIs for communication. Recently, HPE Aruba Networking redesigned the Ansible integration to utilize a Python SDK known as pyaoscx for all REST-API based modules. This transition improves performance and reliability. To support this, users must install the pyaoscx package using Python 3 pip:

pip3 install pyaoscx

The AOS-CX Ansible Collection is designed to be intelligent; it automatically detects the presence of pyaoscx and will utilize this method if the ansible_network_os variable is set to aoscx. While previous implementations still function, they are no longer supported for future modules, making the update to pyaoscx and the corresponding inventory variables mandatory for long-term stability.

The SSH and CLI Implementation

For tasks that cannot be performed via API, Ansible uses the network_cli connection method. This allows the control node to establish an SSH session with the switch and execute commands as if a human were typing them into the console.

The "No-Mix" Rule for Playbooks

A critical technical constraint in AOS-CX automation is that REST API modules and SSH/CLI modules cannot be mixed within a single play. This is because each method requires a different ansible_connection type. If a playbook needs to use both, the administrator must create separate plays.

• Play 1: Uses REST API modules with ansible_connection set to arubanetworks.aoscx.aoscx or httpapi.
• Play 2: Uses SSH/CLI modules with ansible_connection set to network_cli.

Detailed Inventory Configuration for AOS-CX

The inventory file is the foundation of the automation process, mapping the control node to the physical or virtual switches. Depending on the connection method, the variables required will change.

REST API Connection Configurations

When utilizing the REST API, there are two primary ways to configure the connection. One uses the specific arubanetworks.aoscx.aoscx connection, while the other uses the more generic httpapi.

Configuration via arubanetworks.aoscx.aoscx

This method is optimized for the pyaoscx SDK. The inventory requires specific proxy and certificate variables:

• ansible_connection: Must be arubanetworks.aoscx.aoscx.
• ansible_aoscx_validate_certs: Boolean (True/False) to determine if SSL certificates should be verified.
• ansible_aoscx_use_proxy: Boolean to determine if the connection should bypass environment proxies.
• ansible_acx_no_proxy: Boolean to ensure the connection does not go through a proxy.

Example Inventory: yaml all: hosts: 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

Configuration via httpapi

This is an alternative REST connection method. The variables differ slightly:

• ansible_connection: Set to httpapi.
• ansible_httpapi_validate_certs: Boolean for certificate validation.
• ansible_httpapi_use_ssl: Boolean to enable SSL.
• ansible_acx_no_proxy: Boolean for proxy bypass.

Example Inventory: yaml all: hosts: 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

SSH/CLI Connection Configuration

For CLI-based automation, the inventory is simplified, focusing on the network CLI connection:

• ansible_connection: Must be network_cli.
• ansible_network_os: Must be arubanetworks.aoscx.aoscx.

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

Implementing AOS-CX Playbooks

Once the inventory is established, the administrator can create playbooks to manage the device state. A primary example is the creation of Layer 3 interfaces.

Example L3 Interface Configuration

To configure a network interface, the aoscx_l3_interface module is used. This requires the specification of the interface ID, a description, and the associated IP 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 scenario, the gather_facts: False parameter is essential to prevent Ansible from attempting to collect general system information using default modules that may not be compatible with the current connection method.

Aruba Central Automation and API Integration

Automating Aruba Central differs significantly from automating individual switches. When targeting Classic Central, the inventory does not contain every switch in the network; instead, it contains the Central instance itself, which then manages the downstream devices.

Connection Parameters for Classic Central

The connection to Aruba Central is strictly handled via the httpapi method. The following variables must be defined in the inventory:

• ansible_host: This must be the Base URL path for the API-gateway on Classic Central, provided in Fully Qualified Domain Name (FQDN) format.
• ansible_connection: This must be set to httpapi.
• ansible_network_os: This must be set to aruba_central.
• ansible_httpapi_use_ssl: This must always be set to True to ensure encrypted communication.
• ansible_httpapi_central_access_token: This is the API access token for Classic Central.

Example Inventory for Aruba Central: yaml all: hosts: central: ansible_host: internal-apigw.central.arubanetworks.com ansible_connection: httpapi ansible_network_os: aruba_central ansible_httpapi_use_ssl: True ansible_httpapi_central_access_token: CnjDaXXxvnjrvJRwxxxxXXxxXXXXxxxx

Token Management and Security

The ansible_httpapi_central_access_token is a critical security component. It is important to note that these tokens have a strict expiration policy. A token will expire after two hours, at which point a new token must be generated. Currently, this expiry time is not configurable, requiring the automation engineer to implement a process for token refreshment to avoid playbook failures.

Conclusion

The synergy between Ansible and HPE Aruba Networking provides a robust framework for eliminating manual configuration errors and accelerating network deployment. By utilizing the arubanetworks.aoscx and arubanetworks.aruba_central collections, administrators can achieve a high degree of consistency across their infrastructure. The transition toward the pyaoscx SDK highlights a commitment to modernizing API interactions, though it requires careful management of the control node's Python environment. The most significant operational hurdle is the strict separation of REST API and SSH/CLI plays, as well as the short lifespan of the Aruba Central API tokens. When these technical constraints are managed through precise inventory variables and structured playbooks, Ansible transforms from a simple scripting tool into a comprehensive orchestration engine capable of managing complex, multi-vendor environments.

Sources

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