Name	Name	Last commit message	Last commit date
parent directory ..
images	images
README.es.md	README.es.md
README.ja.md	README.ja.md
README.md	README.md
gathered.yml	gathered.yml
multivendor.yml	multivendor.yml
resource.yml	resource.yml

Exercise 4: Ansible Network Resource Modules

Read this in other languages: English, 日本語, Español.

If you are using an all Cisco workbench (all four routers are Cisco IOS routers) please switch to these directions.

Objective
Guide
Takeaways
Solution
Complete

Objective

Demonstration use of Ansible Network Resource Modules

Ansible network resource modules simplify and standardize how you manage different network devices. Network devices separate configuration into sections (such as interfaces and VLANs) that apply to a network service.

Network resource modules provide a consistent experience across different network devices. This means you will get an identical experience across multiple vendors. For example the VLANs module will work identically for the following modules:

arista.eos.vlans
cisco.ios.vlans
cisco.nxos.vlans
cisco.iosxr.vlans
junipernetworks.junos.vlans

Configuring VLANs on network devices is an extremely common task, and mis-configurations can cause headaches and outages. VLAN configurations also tend to be identical across multiple network switches resulting in a perfect use case for automation.

This exercise will cover:

Configuring VLANs on Arista EOS
Building an Ansible Playbook using the arista.eos.vlans module.
Understanding the state: merged
Understanding the state: gathered

Guide

Step 1 - Verify VLAN configuration

From the control node terminal, you can ssh rtr2 and type enable

$ ssh rtr2
Last login: Wed Sep  1 13:44:55 2021 from 44.192.105.112
rtr2>enable

Use the command show vlan to examine the VLAN configuration:

rtr2#show vlan
VLAN  Name                             Status    Ports
----- -------------------------------- --------- -------------------------------
1     default                          active

Use the show run | s vlan to examine the VLAN running-confgiuration on the Arista device:
```
rtr2#show run | s vlan
rtr2#
```

As you can see in the output above there is no VLAN configuration outside of the default VLAN 1 (which is not assigned any ports).

Step 2 - Creating the Ansible Playbook

Create a new file in Visual Studio Code named resource.yml

Copy the following Ansible Playbook into your resource.yml

---
- name: configure VLANs
 hosts: arista
 gather_facts: false

 tasks:

 - name: use vlans resource module
   arista.eos.vlans:
     state: merged
     config:
       - name: desktops
         vlan_id: 20
       - name: servers
         vlan_id: 30
       - name: printers
         vlan_id: 40
       - name: DMZ
         vlan_id: 50

Setup will look similar to the following in Visual Studio Code:

Step 3 - Examine the Ansible Playbook

First lets examine the first four lines:
```
---
- name: configure VLANs
  hosts: arista
  gather_facts: false
```
- The --- designates this is a YAML file which is what we write playbooks in.
- name is the description of what this playbook does.
- hosts: arista will execute this playbook only on the Arista network devices.
- gather_facts: false this will disable fact gathering for this play, by default this is turned on.
For the second part we have one task that uses the arista.eos.vlans
```
  tasks:

  - name: use vlans resource module
    arista.eos.vlans:
      state: merged
      config:
        - name: desktops
          vlan_id: 20
        - name: servers
          vlan_id: 30
        - name: printers
          vlan_id: 40
        - name: DMZ
          vlan_id: 50
```
- name: - just like the play, each task has a description for that particular task
- state: merged - This is the default behavior of resource modules. This will simply enforce that the supplied configuration exists on the network device. There is actually seven parameters possible for resource modules:
  - merged
  - replaced
  - overridden
  - deleted
  - rendered
  - gathered
  - parsed
  Only two of these parameters will be covered in this exercise, but additional are available in the supplemental exercises.
- config: - this is the supplied VLAN configuration. It is a list of dictionaries. The most important takeaway is that if the module was change from arista.eos.vlans to junipernetworks.junos.vlans it would work identically. This allows network engineers to focus on the network (e.g. VLAN configuration) versus the vendor syntax and implementation.

Step 4 - Execute the Ansible Playbook

Execute the playbook using the ansible-navigator run. Since there is just one task we can use the --mode stdout
```
$ ansible-navigator run resource.yml --mode stdout
```

The output will look similar to the following:

$ ansible-navigator run resource.yml --mode stdout

PLAY [configure VLANs] *********************************************************

TASK [use vlans resource module] ***********************************************
changed: [rtr4]
changed: [rtr2]

PLAY RECAP *********************************************************************
rtr2                       : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
rtr4                       : ok=1    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Re-running the playbook will demonstrate the concept of idempotency

$ ansible-navigator run resource.yml --mode stdout

PLAY [configure VLANs] *********************************************************

TASK [use vlans resource module] ***********************************************
ok: [rtr2]
ok: [rtr4]

PLAY RECAP *********************************************************************
rtr2                       : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
rtr4                       : ok=1    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

As you can see in the output, everything will return ok=1 indiciating that no changes were taken place.

Step 5 - Verify VLAN configuration

From the control node terminal, you can ssh rtr2 and type enable

$ ssh rtr2
Last login: Wed Sep  1 13:44:55 2021 from 44.192.105.112
rtr2>enable

Use the command show vlan to examine the VLAN configuration:

rtr2#show vlan
VLAN  Name                             Status    Ports
----- -------------------------------- --------- -------------------------------
1     default                          active   
20    desktops                         active   
30    servers                          active   
40    printers                         active   
50    DMZ                              active

Use the show run | s vlan to examine the VLAN running-confgiuration on the Arista device:

rtr2#sh run | s vlan
vlan 20
   name desktops
!
vlan 30
   name servers
!
vlan 40
   name printers
!
vlan 50
   name DMZ

As you can see, the resource module configured the Arista EOS network device with the supplied configuration. There are now five total VLANs (including the default vLAN 1).

Step 6 - Using the gathered parameter

Create a new playbook named gathered.yml

---
- name: configure VLANs
  hosts: arista
  gather_facts: false

  tasks:

  - name: use vlans resource module
    arista.eos.vlans:
      state: gathered
    register: vlan_config

  - name: copy vlan_config to file
    copy:
      content: "{{ vlan_config | to_nice_yaml }}"
      dest: "{{ playbook_dir }}/{{ inventory_hostname }}_vlan.yml"

The first task is identical except the state: merged has been switched to gathered, the config is no longer needed since we are reading in the configuration (verus applying it to the network device), and we are using the register to save the output from the module into a variable named vlan_config
The second task is copying the vlan_config variable to a flat-file. The double currly brackets denotes that this is a variable.
The | to_nice_yaml is a filter, that will transform the JSON output (default) to YAML.
The playbook_dir and inventory_hostname are special varaible also referred to as magic variables. The playbook_dir simply means the directory we executed the playbook from, and the inventory_hostname is the name of the device in our inventory. This means the file will be saved as ~/network-workshop/rtr2_vlan.yml and ~/network-workshop/rtr4_vlan.yml for the two arista devices.

Step 7 - Execute the gathered playbook

Execute the playbook using the ansible-navigator run.
```
$ ansible-navigator run gathered.yml --mode stdout
```

The output will look similar to the following:

$ ansible-navigator run gathered.yml --mode stdout

PLAY [configure VLANs] *********************************************************

TASK [use vlans resource module] ***********************************************
ok: [rtr4]
ok: [rtr2]

TASK [copy vlan_config to file] ************************************************
changed: [rtr2]
changed: [rtr4]

PLAY RECAP *********************************************************************
rtr2                       : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0   
rtr4                       : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Step 8 - Examine the files

Open the newly created files that gathered the VLAN confgiuration from the Arista network devices.
The two files were saved to ~/network-workshop/rtr2_vlan.yml and ~/network-workshop/rtr4_vlan.yml for the two arista devices.
Here is a screenshot:

Takeaways

Resource modules have a simple data structure that can be transformed to the network device syntax. In this case the VLAN dictionary is transformed into the Arista EOS network device syntax.
Resource modules are Idempotent, and can be configured to check device state.
Resource Modules are bi-directional, meaning that they can gather facts for that specific resource, as well as apply configuration. Even if you are not using resource modules to configure network devices, there is a lot of value for checking resource states.
The bi-directional behavior also allows brown-field networks (existing networks) to quickly turn their running-configuration into structured data. This allows network engineers to get automation up running more quickly and get quick automation victories.

Solution

The finished Ansible Playbook is provided here for an answer key:

Complete

You have completed lab exercise 4

As stated previously only two of the resource modules parameters were covered in this exercise, but additional are available in the supplemental exercises.

In the next exercise we will start using Automation controller.

Previous Exercise | Next Exercise

Click here to return to the Ansible Network Automation Workshop

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

4-resource-module

4-resource-module

README.md

Exercise 4: Ansible Network Resource Modules

Table of Contents

Objective

Guide

Step 1 - Verify VLAN configuration

Step 2 - Creating the Ansible Playbook

Step 3 - Examine the Ansible Playbook

Step 4 - Execute the Ansible Playbook

Step 5 - Verify VLAN configuration

Step 6 - Using the gathered parameter

Step 7 - Execute the gathered playbook

Step 8 - Examine the files

Takeaways

Solution

Complete

In the next exercise we will start using Automation controller.

Files

4-resource-module

Directory actions

More options

Directory actions

More options

Latest commit

History

4-resource-module

Folders and files

parent directory

README.md

Exercise 4: Ansible Network Resource Modules

Table of Contents

Objective

Guide

Step 1 - Verify VLAN configuration

Step 2 - Creating the Ansible Playbook

Step 3 - Examine the Ansible Playbook

Step 4 - Execute the Ansible Playbook

Step 5 - Verify VLAN configuration

Step 6 - Using the gathered parameter

Step 7 - Execute the gathered playbook

Step 8 - Examine the files

Takeaways

Solution

Complete

In the next exercise we will start using Automation controller.