Welcome to the YAML Lab¶

File Listing¶

For the YAML lab portion, we will modify some files that are already in our lab working directory. These files will eventually be ingested by Ansible, a tool we will learn about in the next workshop section, and used to fill in the blanks with the Jinja templates we create in the next lab section to finally build our device configurations.

The files and their location are laid out below:

jinjayaml
  group_vars
    - all.yml
  host_vars
    - leaf1.yml
    - leaf2.yml
    - leaf3.yml
    - leaf4.yml
    - spine1.yml
    - spine2.yml

Inventory¶

The files we will modify and enter our data model correspond to an Ansible inventory file. While this will be covered in more detail during the next workshop section, Ansible, the .yml files we will be working with line up as shown below:

---
all: -> group_vars/all.yml
    spine1: -> host_vars/spine1.yml
    spine2: -> host_vars/spine2.yml
    leaf1: -> host_vars/leaf1.yml
    leaf2: -> host_vars/leaf2.yml
    leaf3: -> host_vars/leaf3.yml
    leaf4: -> host_vars/leaf4.yml

The yaml data model we enter into the all.yml file, will apply to all devices below that group, meaning spine1-2, and leaf1-4.

The yaml data model we enter into each of the respective <host>.yml files will apply to the device of that name.

all.yml Data Model¶

The first file we will be modifying will be the all.yml file in the group_vars directory.

After the file is opened, you will notice some pre-existing data models and spots where there are missing data models. Our goal in this section of the lab is to create our missing data model using what we learned about the different YAML constructs.

Below are the sections of the data model we want to complete. Try to infer from the existing data model and the CLI syntax defined in the comments the most efficient data model syntax to create. If you struggle to come up with a solution, don't worry; there are hints below each section with a possible answer.

Create the data model necessary to configure aaa authorization for all switches.
Hint - AAA Authorization

Looking at the aaa authentication section above, we can create a similar, nested key value pair:
```
aaa_authorization:
  exec:
    default: group radius local
```
Now let's add an additional host definition to our current radius_servers data model. We want to add a host of 192.168.1.11, VRF of MGMT, and the key of newradkey.
Hint - RADIUS Server

Looking at the current data model, we can add a new list entry with the same syntax. When finished, it could look like this:
```
radius_servers:
   - host: 192.168.1.10
     vrf: MGMT
     key: radiusserverkey
   - host: 192.168.1.11
     vrf: MGMT
     key: newradkey
```
Next, lets configure the RADIUS source-interface, using the Management1 interface in vrf MGMT.
Hint - RADIUS Source Interface

Looking at the above syntax for HTTP client source interface, we can come up with something similar for RADIUS.
```
ip_radius_source_interfaces:
  - name: Management1
    vrf: MGMT
```
Now we will define our data model to configure the three name servers listed in the comment: 1.1.1.1, 4.4.4.4, 8.8.8.8
Hint - Name Servers

For this data model a simple list will suffice. What you want for your top level key is up to you, but it should be easy to read!
```
name_servers:
  - 1.1.1.1
  - 4.4.4.4
  - 8.8.8.8
```
Finally, we will enter our data model to set the clock timezone for all switches. We want to ensure the timezone is set to EST5EDT.
Hint - Clock Time Zone

For the final piece of data model we are back to a simple, nested key value pair.
```
clock:
  timezone: EST5EDT
```

Now that we have finished entering our data model that applies to all devices in our inventory, lets build the rest of our data model specific to each device.

host_vars Data Models¶

While the data model in the all.yml vars file applies configuration at the group level to every device, to apply a configuration specific to each host, we are going to define some items, like interfaces and VLANs, in each host-specific vars file. Some of the data models will already exist, and we will just add to it and move it around to other hosts using what's there as examples.

The end goal of the data models we will be creating and modifying here will be to configure the physical interfaces connecting the spines and leafs, as well as deploy the necessary VLANs at layer 2 and layer 3 where we want them to go.

The below tables will lay out the VLANs we want to configure and where they should be configured:

L2 VLAN Assignments¶

Node	VLAN
spine1	10, 20
spine2	10, 20
leaf1	10
leaf2	10
leaf3	20
leaf4	20

L3 VLAN Assignments¶

Node	VLAN	Host IP	VIP
spine1	10	10.10.10.2/24	10.10.10.1
spine2	10	10.10.10.3/24	10.10.10.1
spine1	20	20.20.20.2/24	20.20.20.1
spine2	20	20.20.20.3/24	20.20.20.1

Lets use the spine1.yml vars file within host_vars as our jumping off point for creating the necessary data models.

Hint - VLAN Data Models

Here is one example of some data models you could use for each hosts vars file.

spine1spine2leaf1 / leaf2leaf3 / leaf4

vlans:
  - id: 10
    name: "ten"
  - id: 20
    name: "twenty"

svis:
  - id: 10
    desc: "ten"
    host_ip: "10.10.10.2/24"
    vip: "10.10.10.1"
  - id: 20
    desc: "twenty"
    host_ip: "20.20.20.2/24"
    vip: "20.20.20.1"

vlans:
  - id: 10
    name: "ten"
  - id: 20
    name: "twenty"

svis:
  - id: 10
    desc: "ten"
    host_ip: "10.10.10.3/24"
    vip: "10.10.10.1"
  - id: 20
    desc: "twenty"
    host_ip: "20.20.20.3/24"
    vip: "20.20.20.1"

vlans:
  - id: 10
    name: "ten"

vlans:
  - id: 20
    name: "twenty"

Interface Assignments¶

For this section we want to specify the data models necessary to configure the interfaces that both interconnect the spines and leafs, as well as any endpoints that may be connected to our leaf switches. Using the table below, and the leaf1.yaml vars file in host_vars, lets build our data model.

spine1spine2leaf1leaf2leaf3leaf4

Node	Interface	Description	Mode	VLANs
spine1	Ethernet1	To_Leaf1	trunk	n/a
spine1	Ethernet2	To_Leaf2	trunk	n/a
spine1	Ethernet3	To_Leaf3	trunk	n/a
spine1	Ethernet4	To_Leaf4	trunk	n/a
spine1	Ethernet48	To_Spine2	trunk	n/a

Node	Interface	Description	Mode	VLANs
spine2	Ethernet1	To_Leaf1	trunk	n/a
spine2	Ethernet2	To_Leaf2	trunk	n/a
spine2	Ethernet3	To_Leaf3	trunk	n/a
spine2	Ethernet4	To_Leaf4	trunk	n/a
spine2	Ethernet48	To_Spine1	trunk	n/a

Node	Interface	Description	Mode	VLANs
leaf1	Ethernet1	To_Spine1	trunk	n/a
leaf1	Ethernet2	To_Spine2	trunk	n/a
leaf1	Ethernet10	Host1	access	10
leaf1	Ethernet48	To_Leaf2	trunk	n/a

Node	Interface	Description	Mode	VLANs
leaf2	Ethernet1	To_Spine1	trunk	n/a
leaf2	Ethernet2	To_Spine2	trunk	n/a
leaf2	Ethernet48	To_Leaf1	trunk	n/a

Node	Interface	Description	Mode	VLANs
leaf3	Ethernet1	To_Spine1	trunk	n/a
leaf3	Ethernet2	To_Spine2	trunk	n/a
leaf3	Ethernet10	Host2	access	20
leaf3	Ethernet48	To_Leaf4	trunk	n/a

Node	Interface	Description	Mode	VLANs
leaf4	Ethernet1	To_Spine1	trunk	n/a
leaf4	Ethernet2	To_Spine2	trunk	n/a
leaf4	Ethernet48	To_Leaf3	trunk	n/a

Hint - Interface Data Models

Here is one example of some data models you could use for each hosts vars file.

spine1spine2leaf1leaf2leaf3leaf4

interfaces:
  Ethernet1:
    descr: "To_Leaf1"
    mode: "trunk"
  Ethernet2:
    descr: "To_Leaf2"
    mode: "trunk"
  Ethernet3:
    descr: "To_Leaf3"
    mode: "trunk"
  Ethernet4:
    descr: "To_Leaf4"
    mode: "trunk"
  Ethernet48:
    descr: "To_Spine2"
    mode: "trunk"

interfaces:
  Ethernet1:
    descr: "To_Leaf1"
    mode: "trunk"
  Ethernet2:
    descr: "To_Leaf2"
    mode: "trunk"
  Ethernet3:
    descr: "To_Leaf3"
    mode: "trunk"
  Ethernet4:
    descr: "To_Leaf4"
    mode: "trunk"
  Ethernet48:
    descr: "To_Spine1"
    mode: "trunk"

interfaces:
  Ethernet1:
    descr: "To_Spine1"
    mode: "trunk"
  Ethernet2:
    descr: "To_Spine2"
    mode: "trunk"
  Ethernet10:
    descr: "Host1"
    mode: "access"
    vlan: 10
  Ethernet48:
    descr: "To_Leaf2"
    mode: "trunk"

interfaces:
  Ethernet1:
    descr: "To_Spine1"
    mode: "trunk"
  Ethernet2:
    descr: "To_Spine2"
    mode: "trunk"
  Ethernet48:
    descr: "To_Leaf1"
    mode: "trunk"

interfaces:
  Ethernet1:
    descr: "To_Spine1"
    mode: "trunk"
  Ethernet2:
    descr: "To_Spine2"
    mode: "trunk"
  Ethernet10:
    descr: "Host2"
    mode: "access"
    vlan: 20
  Ethernet48:
    descr: "To_Leaf4"
    mode: "trunk"

interfaces:
  Ethernet1:
    descr: "To_Spine1"
    mode: "trunk"
  Ethernet2:
    descr: "To_Spine2"
    mode: "trunk"
  Ethernet48:
    descr: "To_Leaf3"
    mode: "trunk"

Onto the Jinja Content¶

Now that we have built our data models, lets move on to learn about Jinja templating and make use of all this yaml to render device configurations!

Continue to the Jinja Content