Ansible Two-Tier Inventory

An Ansible inventory file serves two primary functions for AOS-CX automation: it defines the set of switches to apply automated configuration, and it defines a set of variables that provide configuration values for those switches.

YAML Inventory File

Ansible inventory files are formatted using YAML data structures. The Two-Tier data center inventory file provides a reference for formatting host, group, and variable data in an Ansible automation.

Red Hat’s How to build your inventory guide provides a general reference on creating inventory files.

The example inventory variable values must be modified to align with the organization’s environment. This includes customizing the host IP addresses, DNS servers, port assignments, etc. This chapter provides background information and the variable names needed to modify the example inventory file successfully for individual needs.

Inventory Hosts

Hosts are the targets for an Ansible playbook automation. They are defined in one or more hosts sections in the inventory file.

An ansible_host variable is assigned to each switch with a fully-qualified DNS name (FQDN), IPv4 address, or IPv6 address value. The playbook uses this value for SSH and API communication with switch management interfaces.

Additional variables are associated with each host that represent the desired configuration state of the target switch. Variable values can be assigned directly to an individual host or inherited through the group structure described in this chapter.

Inventory Variables

Variables defined in the Ansible inventory file serve two general purposes: they specify switch configuration and Ansible playbook behavior. Most variables in the Ansible inventory file represent values assigned to switch configuration statements when the playbook builds a switch configuration file.

All the variables in the example inventory file are necessary for the Two-Tier data center playbook to run properly.

Single Value Assignments

Simple variables assign a single value to the right of the variable name with a colon separator.

mtu: 9198
vsx_role: primary
vsx_system_mac: 02:00:00:00:10:01

List and Dictionary Assignments

It can be advantageous to assign multiple values to a single variable for automating switch configuration.

Lists can be defined using two methods in the inventory file. The first method assigns a set of comma delimited values in square brackets to a variable name. The second method assigns each list member on a new line preceded by a dash.

The second method provides an easily understandable visual structure for creating dictionaries (multidimensional arrays), where each dictionary member contains its own set of nested variables. A dictionary is analogous to an employee record, where each employee is assigned a set of values such as name, address, and phone number.

Example lists from the inventory file are shown below:

ntp_servers: [10.2.120.98, 10.2.120.99]
dns_servers: [10.2.120.98, 10.2.120.99]
vsx_isl_ports: ['1/1/49', '1/1/50']

The following example illustrates how to assign sets of variables in dictionary form to the host_vlans variable. Grouping sets of values in this manner facilitates AOS-CX config automation in the template file.

host_vlans:
- id: 101
  name: PROD-WEB
  ip_address: 10.12.101.2
  active_gateway_mac: 02:00:0a:01:65:01
  active_gateway_ip: 10.12.101.1
- id: 102
  name: PROD-DB
  ip_address: 10.12.102.2
  active_gateway_mac: 02:00:0a:01:65:01
  active_gateway_ip: 10.12.102.1

AOS-CX Ansible Collection Variables

AOS-CX Ansible Collection variables are reserved names that modify playbook behavior and connectivity to automated hosts.

Some AOS-CX Ansible Collection variables require a specific value, such as the following connection variables.

ansible_connection: arubanetworks.aoscx.aoscx   # DO NOT CHANGE
ansible_network_os: arubanetworks.aoscx.aoscx   # DO NOT CHANGE
ansible_httpapi_use_ssl: True   # DO NOT CHANGE

Inventory Groups

Groups provide a hierarchical structure for the inventory file. Ansible hosts and variables can be defined at any group level in the hierarchy.

In the example deployment, six groups are defined to organize the inventory file into a four-level hierarchy.

Groups enable efficient organization of common configuration elements, similar to Aruba Central. Each host inherits the variables assigned to groups in its path hierarchy. This enables assigning common configuration elements on multiple affinities, such as data center location, functional role, or rack.

Core switch hosts are defined in the core group. Server access switches are defined in their respective rack group to accommodate configuration common to each VSX pair. For example, server access switches in rack 1 are defined in the rack1 group.

AOS-CX Ansible Collection variables that apply to all switches are defined once in the aoscx_switches group. Configuration values common to all data center switches are defined once in the DC-RSV group. The core and access groups assign configuration common to switches in those respective roles. Configuration values common to access switches in the same rack are defined at the rack level. The rack groups are defined primarily to apply VSX and MC-LAG configuration to redundant top-of-rack switches. Variables that have unique values at each host are defined at the host level for both core and access switches.

The following diagram illustrates a sample variable at each group level inherited by a host and a unique host variable assignment:

When the same variable exists in multiple contexts, the assignment nearest the host in the hierarchy is used by the Ansible playbook. A host variable assignment takes precedence over all group assignments.

The example Ansible group organization is just one approach for categorizing switches with common configuration elements. Organizations should use a grouping methodology that best meets their needs.

Specify a Template File

The playbook uses inventory variables in conjunction with a configuration template to build AOS-CX configuration statements.

When automating more than one switch model or role, some configuration elements may be unique to the model or role. Two examples include:

• Assigning switch profiles to optimize hardware resources with a switch’s network functions. Switch profile names are not consistent across all switch models.
• In the Two-Tier data center, OSPF routing is configured on core switches, but not on server access switches.

A separate template file for core and access switches is used in our example deployment. Standardizing a consistent switch platform for each role can simplify template creation, although additional scripting logic can be applied in a template file to accommodate model differences.

It is best practice to use different configuration templates for each switch role for efficient template file administration.

The configuration templates are assigned to a host with the config_template inventory variable. In this project, the config_template variable is assigned in the core and access group contexts.

config_template: templates/2TierV2/access.j2

Configuration templates are described further in the Ansible Template chapter.

Planning Inventory File Values

This section provides sample values and rationale for naming and numbering schemes. Adjust values and formats as needed to accommodate specific requirements. Use a consistent approach in the physical and logical configurations to improve network management and troubleshooting.

Naming Conventions

Establish a switch naming convention that indicates the switch type, role, and location to simplify identification and increase operating efficiency.

Example values used in this guide:

In the Ansible inventory file, the switch name is defined as an Ansible inventory name in the hosts stanza. For example, the inventory name RSVDC-ACCESS-1-1 is created in the hosts stanza in the DC-RSV > access > rack1 group context. Each link in the table above references the location in the inventory file for a specific switch’s inventory name.

When executing the playbook, the hostname in the configuration file is set based on the current iterated switch inventory name.

IP Address Planning

Plan a consistent IP numbering scheme with values that can accommodate the current deployment size and leave room for growth. Define a range that can represent loopback addresses, IP addresses used in supporting protocols, and a range for data center hosts. It is beneficial to assign data center host subnets from a larger range of maskable IP addresses that summarizes all host subnets in the data center.

Example IP address ranges used in this guide:

The Ansible inventory statically defines all the IP addresses needed, including loopback addresses and routed interfaces. Each link in the table above references the location in the inventory file of an example IP address assigned from the pool. Some values and variables are repeated for devices. Be sure to review all entries in the inventory file before execution.

MAC Address Planning

A Locally Administered Address (LAA) should be used when defining virtual MAC addresses for VSX and active gateway functions. This is required when configuring an Active Gateway for an SVI on a VSX pair and when configuring the system MAC address of VSX. An LAA is a MAC in one of the four formats shown below:

x2-xx-xx-xx-xx-xx 
x6-xx-xx-xx-xx-xx 
xA-xx-xx-xx-xx-xx 
xE-xx-xx-xx-xx-xx

The x positions can contain any valid hex value. It is helpful to create a hexadecimal representation of the associated IP address or VLAN ID using the hex positions. For more details on the LAA format, see the IEEE tutorial guide.

In this guide, VSX system MAC addresses are set to 02:00:00:00:10:xx, where xx is replaced with the rack number of the VSX pair and the core switches use a value of 00.

Active Gateway MAC addresses are set in the format 02:00:0a:xx:xx:xx.

The host_vlans variable defined in the RSV-DC group is redefined for each core switch at the host level. Be mindful to use consistent vlan_id and name values in the inventory file at both levels.

Note: A variable’s value may be reassigned at a different level in the inventory file’s hierarchy for several reasons. In our example, the dictionary values assigned to the host_vlans variable in the DC-RSV group are inherited by all access switches. The core switches require additional variables in the dictionary for their roles in the network, where some values are unique to the host. Redefining the host_vlans variable at each core switch’s host level overwrites the dictionary values defined in the higher group, so it is necessary to include the previously defined vlan_id and name variables in the new dictionary list assignment at the host level.

Inventory Variable Reference

This section describes inventory variables included in this example Ansible AOS-CX playbook automation. The example inventory file provides a complete reference for the Two-Tier data center automation.

The top level aoscx_switches group assigns variables associated to all switch hosts focused on script execution.

The DC-RSV group assigns AOS-CX configuration variables common to all data center switches.

The core group assigns AOS-CX configuration variables common to data center core switches.

Each core switch is assigned a set of variables at the host level. The variables and lists assigned at the host level contain unique values not shared by other switches. The following table shows sample values for the RSVDC-CORE1-1 switch.

The access group assigns AOS-CX configuration variables common to data center access switches.

A rack group assigns AOS-CX configuration variables common to a VSX redundant pair of rack switches. In this example deployment, MC-LAGS are defined at the rack level to accommodate unique description and VLAN assignments per LAG. It is possible to define MC-LAGs for all host-facing ports just once in the access group, when assigning all VLANs to the MC-LAGs without unique descriptions.

Each access switch is assigned a set of variables at the host level. The variables and lists assigned at the host level contain unique values that are not shared by other switches. The following table shows sample values for the RSVDC-ACCESS1-1 switch.