Architecting Network Automation with Cisco ACI and Ansible

The integration of Application Centric Infrastructure (ACI) with Ansible represents a paradigm shift in data center management, moving from manual, imperative configuration to a declarative, Network-as-Code model. Cisco ACI, by design, is a software-defined networking (SDN) solution that centralizes the control plane through the Application Policy Infrastructure Controller (APIC). To interact with this controller, Ansible leverages the ACI REST API over HTTP/HTTPS, allowing engineers to treat infrastructure as software. This synergy enables the rapid deployment of complex multi-tier tenant configurations, the standardization of interface policies, and the systematic rollout of global settings such as Network Time Protocol (NTP) and Domain Name Services (DNS). By utilizing the Cisco ACI Ansible collection, organizations can transition from fragile, manual CLI-based changes to version-controlled, repeatable playbooks that ensure consistency across the entire fabric.

The Cisco ACI Ansible Collection Ecosystem

The foundational component for automating ACI is the Cisco ACI Ansible collection. This collection acts as a library of plugins and modules specifically engineered to map Ansible's declarative language to the APIC's object-oriented data model.

Installation and Version Management

The deployment of the ACI collection can be achieved through multiple vectors, depending on whether the user requires the stable release from the Ansible Galaxy ecosystem or the latest development features from the source code.

The standard method for installation involves the ansible-galaxy CLI. To install the current version, the following command is utilized:

ansible-galaxy collection install cisco.aci

For environments requiring a specific version to maintain compatibility with legacy playbooks or specific APIC firmware versions, a version-specific installation is possible:

ansible-galaxy collection install cisco.aci:==1.0.0

Furthermore, administrators must periodically update the collection to access new modules and bug fixes. The upgrade process is handled via:

ansible-galaxy collection install cisco.aci --upgrade

Advanced Installation from Source

For power users and developers who need the bleeding-edge features found in the ansible-aci repository, a manual build process is available. This involves cloning the repository from GitHub, navigating to the directory, and building the collection locally.

The sequence of operations is as follows:

git clone https://github.com/CiscoDevNet/ansible-aci.git cd ansible-aci git pull origin master ansible-galaxy collection build --force ansible-galaxy collection install cisco-aci-* --force

Alternatively, users can bypass the build process by navigating to the GitHub Actions tab of the ansible-aci repository. By selecting the latest Continuous Integration (CI) build, users can download pre-compiled artifacts. These artifacts are typically suffixed with the supported Ansible version (for example, collection-stable-2.17). Because these are distributed as zip files containing tar.gz archives, they must be unzipped via the terminal or console before deployment.

Technical Authentication Mechanisms in ACI Automation

Ansible interacts with the APIC via REST API calls. The method of authentication chosen has a profound impact on the performance and security of the automation pipeline.

Standard Username and Password Authentication

The most common method is the username/password combination. In this flow, the Ansible module must perform an aaaLogin sequence to establish a session with the APIC.

The technical consequence of this method is that for every single task execution in a playbook, a new aaaLogin sequence is initiated. When combined with the inherent behavior of ACI modules, this creates a significant overhead. Specifically, each create or delete operation triggers two GET requests: one to verify the existence of the object before the operation and one to verify the success of the operation afterward. Consequently, a loop creating multiple objects will result in a repetitive cycle of aaaLogin -> GET -> POST -> GET, which can either throttle the APIC or significantly slow down the playbook execution time.

Signature-Based Transactions with X.509 Certificates

To resolve the performance bottlenecks of session-based authentication, Cisco provides signature-based transactions. In this model, local users within the APIC are assigned an optional X.509 certificate (public key) as an attribute. The client (the Ansible control node) holds the corresponding private key.

Each API request is signed using SHA-256, creating a unique cryptographic signature. This provides several technical and operational advantages:

1. Elimination of the aaaLogin sequence: Because each transaction carries its own signature, the APIC can validate the identity of the client without a separate login step.
2. Enhanced Security: The SHA-256 digest prevents man-in-the-middle (MITM) tampering attempts, ensuring the integrity of the request.
3. Performance Gains: The removal of the login overhead results in a significant increase in execution speed, particularly during large-scale deployments involving loops.

The trade-off for this security is computational; a longer key length increases the time required to calculate the unique SHA-256 hash.

Operational Implementation and Playbook Development

Developing effective ACI playbooks requires an understanding of both the Ansible environment and the specific modules provided by the cisco.aci collection.

Environment Setup and Linux Distribution

While the choice of Linux distribution does not fundamentally alter the functionality of Ansible, the available package versions in official repositories can vary. For instance, Debian Stable may provide an older version of Ansible (such as 2.7.7) in its default repository, which is insufficient for the cisco.aci collection, as it requires Ansible 2.9 or newer.

To ensure a compatible environment, administrators should install the following prerequisite tools:

apt-get install software-properties-common vim yamllint ansible-lint

Documentation and Module Discovery

The ACI collection is extensive, making it difficult to memorize every module. The ansible-doc command is the primary tool for discovering the requirements and arguments for any given module. The syntax follows the pattern ansible-doc cisco.aci.<module-name>.

For example, to find the specific requirements for configuring LLDP policies on an interface, the following command is used:

ansible-doc cisco.aci.aci_interface_policy_lldp

This command provides the technical specifications and usage examples necessary to build a functional playbook.

Comparative Analysis of Authentication Methods

The following table delineates the technical and operational differences between the two primary authentication methods used by Ansible to communicate with the APIC.

Deep Dive into Playbook Execution and Performance

To analyze the efficiency of an ACI deployment, it is critical to measure the execution time of tasks. This is achieved by configuring the ansible.cfg file with the following setting:

callbacks_enabled = profile_tasks

Note that this specific functionality requires the installation of ansible.posix.

Analysis of Loop Execution

Consider a scenario where a playbook is designed to create five tenants using a loop. The configuration would look as follows:

```yaml

• name: create N tenants with a loop hosts: dot34 connection: local vars: acicreds: &acilogin hostname: '{{ inventoryhostname }}' username: '{{ ansibleuser }}' password: '{{ ansiblepassword }}' validatecerts: no use_proxy: no myState: "present" tasks:
  • name: tenant loop acitenant: <<: *acilogin tenant: "{{ 'tenantLoopUser-%02x' | format(item) }}" description: performance testing state: '{{ myState }}' loop: "{{ range(1,6) }}" ```

In a standard password-based authentication environment, the execution of this loop results in a repetitive sequence of API calls for each item:

• One aaaLogin sequence.
• One GET request to check if the tenant already exists.
• One POST request to create the tenant.
• One GET request to verify the creation was successful.

This behavior is hardcoded into the design of the ACI Ansible modules and cannot be altered via configuration settings. When using the signature-based approach, the aaaLogin step is removed, drastically reducing the total elapsed time.

Example Performance Output

The following represents a typical execution output for the tenant loop task:

PLAY [create N tenants with a loop] TASK [tenant loop hostname={{ inventory_hostname }}, username={{ ansible_user }}, password={{ ansible_password }}, validate_certs=False, use_proxy=False, tenant={{ 'tenantLoopUser-%02x' | format(item) }}, description=performance testing, state={{ myState }}] *** Thursday 06 April 2023 08:17:23 +0000 (0:00:00.018) 0:00:00.018 ******** changed: [10.48.168.3] => (item=1) changed: [10.48.168.3] => (item=2) changed: [10.48.168.3] => (item=3) changed: [10.48.168.3] => (item=4) changed: [10.48.168.3] => (item=5) PLAY RECAP 10.61.124.34 : ok=1 changed=1 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0 Thursday 06 April 2023 08:17:26 +0000 (0:00:03.227) 0:00:03.246 ********

This output demonstrates that while the total time for five tenants may seem minimal, the cumulative effect of these overheads in a production environment with hundreds of objects becomes a critical performance bottleneck.

Comprehensive Automation Use Cases

The Cisco ACI Ansible collection is designed to handle a wide array of configuration tasks, ranging from basic fabric settings to complex tenant topologies.

Fabric-Level Configurations

Automation can be applied to global services that are essential for fabric stability and reachability:

• Network Time Protocol (NTP): Ensuring all leaf and spine switches are synchronized.
• Domain Name Services (DNS): Configuring the fabric's ability to resolve hostnames.
• Border Gateway Protocol (BGP) Route Reflector: Automating the routing architecture for scalability.

Resource Provisioning

Playbooks can be utilized to provision the underlying physical and logical resources of the ACI fabric:

• Interface Configuration: Setting up physical ports and associating them with policies.
• Interface Policies: Defining LLDP, CDP, and other layer 2 policies.
• VLAN Pools: Creating and managing the range of VLANs available in the fabric.
• Domains: Defining the physical and logical boundaries for network services.

Tenant and L3Out Architecture

One of the most powerful applications of Ansible in ACI is the deployment of multi-tier tenant configurations. This involves the creation of tenants, VRFs, Bridge Domains (BDs), and Application Profile (AP) objects. Furthermore, the collection supports the configuration of various types of L3Outs, allowing the ACI fabric to communicate with external networks and legacy routers.

Conclusion

The integration of Ansible with Cisco ACI transforms the data center from a collection of manually managed devices into a programmable entity. The technical shift from session-based aaaLogin sequences to signature-based X.509 authentication is not merely a security upgrade but a critical performance optimization that enables scalable automation. By leveraging the cisco.aci collection and the ansible-doc utility, engineers can move away from the risks associated with manual configuration and embrace a declarative model where the state of the network is defined in code. The ability to deploy everything from basic NTP settings to complex L3Out configurations through a single control node ensures that the ACI fabric remains consistent, verifiable, and agile in the face of changing business requirements.

Sources

1. Automating ACI using Ansible
2. ACI and Ansible
3. CiscoDevNet ansible-aci GitHub Repository