Under the majority of the role directories you'll notice a ".yml" file. Playbooks are written in a simple markup language called YAML, which stands for YAML Ain't Markup Language. YAML is used as it's even easier to read than data structure formats such as XML or JSON that you have previously examined.
YAML files optionally begin with --- at the top of the file to signify the start of the file. Following the
file start, comes the Ansible modules written in YAML syntax. YAML syntax for Ansible modules are expressed as a list
of key/value pairs. A list simply begins with a "- " (a dash followed by a space) while, as in previous examples,
dictionaries use ":".
Below you can see an example of YAML syntax that contains a list of dictionaries and where the dictionaries contain lists:
- name: CONFIGURE PIM ANYCAST RP
cisco.nxos.nxos_config:
lines:
- ip pim anycast-rp {{ rp_address }} {{ s1_loopback }}
- ip pim anycast-rp {{ rp_address }} {{ s2_loopback }}
- name: CONFIGURE PIM RP
cisco.nxos.nxos_pim_rp_address:
rp_address: "{{ rp_address }}"
In the example above, you were introduced to two things:
cisco.nxos.nxos_config
and cisco.nxos.nxos_pim_rp_address
which are existing Ansible Network modules from the Cisco NXOS collection.
Within the documentation for each network module there is a synopsis of what function the module performs and a table of parameters or keys. The tabulated parameters inform the user which parameters are required for the module to function as a task, which parameters are optional, and what the defaults are for those parameters.
As an example, each of these core network modules have basic requirements for arguments to access the device, albeit, some of these parameters may not apply to the network operating system you work with:
Ansible allows you to define and reference variables in your playbook tasks using Jinja2 templating; a templating
language for Python. A YAML gotcha for Jinja2 is that if you start the line with a Jinja2 templated variable, for
example "{{inventory_hostname}}"
, then the entire line must be in quotes.
Variables can be defined in various locations and
Ansible has a precedence system for understanding what and when a variable would be overridden if used in more
than one location. The precedence for a variable can be seen below. As an example, a variable in the role defaults
directory would be overridden by a variable in the playbook global_vars/all directory and file. Further, both of these are
overridden by the local vars directory within the specific role, role vars.
Create an ansible.cfg file to disable hostkey checking and set your python interpreter for the purposes of this lab.
Copy the below YAML into the your Terminal window to create the all file and populate contents of the file
for the ansible_connection
, ansible_network_os
, and username/password information used to connect direct to the devices.
This all YAML file also contains OSPF parameters and NTP server information that is used across all devices.
Again, this is a file with key/value pairs. group_vars/all is where you place universal variables that apply for all devices.
For passwords, it is best practice to leverage something like Ansible Vault. For simplicity, clear text is used.
Copy the below YAML into the spine role vars directory main.yml file. The variables here will be used to configure specific features for VXLAN EVPN and BGP parameters. Remember, each of these are a dictionary with key/value pairs or a dictionary that contains a list of dictionaries.
Copy the below YAML into the leaf role vars directory main.yml file. The variables here will be used to for specific features for VXLAN EVPN, BGP parameters, SVI parameters, and VXLAN parameters, such as tenant VRFs and VLANs mapped to specific VNIs. Remember, each of these are a dictionary with key/value pairs or a dictionary that contains a list of dictionaries.
For each role, you are now going to create the variables to be used per device and commonly across all devices specified within the role. The device specific variables will be defined under the host_vars directory for each device. The common variables to be used across all devices will be defined under roles/spine/vars/main.yml and roles/leaf/vars/main.yml respectively.
Copy the below YAML files into the host_vars directory for your Spine1 device. These device specific variables include physical interface information, such as IP addressing, and Loopback interface information for Underlay routing, such as peering, router-id and PIM RP address.
In this YAML file, you will see the use of the anchor and alias feature of YAML. This is a way to reuse pieces of YAML in other parts of a YAML file. Here, you create two different data structures for two different types of layer 3 interfaces. Then, you combine them into a list of layer 3 interfaces.
Copy the below YAML files into the host_vars directory for your Leaf1 device. Like your spine device specific variables include physical interface information, such as IP addressing, and Loopback interface information for Underlay routing, such as for peering, router-id, etc and VTEP address.
Copy the below YAML files into the host_vars directory for your Leaf2 device. Like your spine device specific variables include physical interface information, such as IP addressing, and Loopback interface information for Underlay routing, such as for peering, router-id, etc and VTEP address.
With all your variables in place, continue to the next section to build the tasks for configuring the VXLAN EVPN fabric.