Data Model Structure

Like the investment and thought that went into the hosts structure, a lot of up-front time and planning is required to build data model structures. Some basic formatting standards, variable naming conventions, and a variable dictionary hierarchy should be established and followed rigidly.

group_vars

As part of the repository structure, there is a folder called group_vars. This is an Ansible-specific folder used to set up data models for the groups configured in the hosts file. Group variables are applied to all common hardware platforms or logical functions. If, for example, a common QoS policy is configured on all the distribution switches, abstract the QoS policy data into a model in the CAMPUS-DISTRIBUTION.yml group_vars file.

[CAMPUS-DISTRIBUTION] can be called a group_vars by creating a YAML file called CAMPUS-DISTRIBUTION.YML inside the group_vars folder. This allows the data model to contain variables that apply to all devices listed in hosts.ini file subsections creating a golden configuration by platform or logical function.

It is a recommended practice to prepend all variables created in group_vars with a common identifier such as platform_, group_, or global_. For example, platform_defaults or group_vlans. Using this naming convention when writing dynamic templates allows for the intent to become obvious to the operator. It also points to a file in the group_vars folder as the source of the data and variable.

The data belonging to group_vars or host_vars should be considered carefully. There are advantages and disadvantages to either approach. Generally, group_vars should contain as many platform or logical function standards as possible and can be used to reflect a solid network design adhering to best practices.

Sometimes using group_vars does not make sense. For example, in the case of a hostname or a management IP address which naturally fits as host_vars. Include host information inside the group_vars where it makes sense. For example, as a standard, all distribution layer switches should have port-channel 1 configured as the uplink port to the core. Port-channels are usually included as a host variable. But in this case, port-channel 1 will be listed under the CAMPUS-DISTRIBUTION.yml group variable.

Some examples of group_vars candidates:

• Standard NTP, IP helper addresses for DHCP, SNMP, or syslog servers

• Access-control lists at the distribution layer

• QoS policies either by platform, logical function, or both

• Banners

• AAA configurations such as RADIUS or TACACS+ servers

• Universal secret

• Standard interfaces:

  • VSS configurations for core and distribution

  • Standardized uplinks

• Domain name

• Native VLAN

• Multicast

• Netflow

• Platform type identifier

• Other features with common code across a platform

host_vars

Similar to group_vars, there is a folder in the repository called host_vars. In this folder, there is a YAML file per device. DIST01.YML is the host_vars file for that specific network host. Store information that is specific and unique to the device on the network in the host_vars YAML files. Depending on the size of the fleet, it may take time to build complete coverage of the devices or configurations. Over time it becomes a matter of cloning an existing host_vars YAML file and replacing the data unique to the device.

It is recommended to prepend host_vars variables with hosts_ for ease of readability, and as a reference point for where the variable is in the repository (in a host_vars file).

Some examples of host_vars variables include:

• Hostname

• Management SVI IP address

• VLANs

• VRFs

• Routing instances

• Switch Virtual Interfaces (SVI)

• Physical interfaces

• Spanning-tree priorities

• Unique secrets or passwords

• DHCP servers

• Switch stack configurations

• Power stack configurations