Read this in other languages: 
English, 
日本語, 
Français.
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.snmp_servercisco.ios.snmp_servercisco.nxos.snmp_servercisco.iosxr.snmp_serverjunipernetworks.junos.snmp_server
Configuring SNMP on network devices is an extremely common task, and mis-configurations can cause headaches and monitoring issues. SNMP configurations also tend to be identical across multiple network switches resulting in a perfect use case for automation.
This exercise will cover:
- Configuring SNMP on Cisco IOS
- Building an Ansible Playbook using the arista.eos.snmp_server module.
- Understanding the
state: merged - Understanding the
state: gathered
-
Login to an Cisco IOS router and verify the current SNMP configuration.
-
From the control node terminal, you can
ssh rtr2and typeenable[student@ansible-1 ~]$ ssh rtr1 rtr1# -
Use the command
show snmpto examine the SNMP configuration:rtr1#show snmp %SNMP agent not enabled
-
Use the
show run | s snmpto examine the SNMP running-configuration on the Cisco device:rtr1#sh run | s snmp rtr1#
As you can see in the output above there is no SNMP configuration on the Cisco router.
-
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: Override commands with provided configuration cisco.ios.snmp_server: config: location: 'Durham' packet_size: 500 communities: - acl_v4: acl_uq name: Durham-community rw: true - acl_v4: acl_uq name: ChapelHill-community rw: true
### Step 3 - Examine the Ansible Playbook
* First lets examine the first four lines:
```yaml
---
- name: configure VLANs
hosts: arista
gather_facts: false
-
The
---designates this is a YAML file which is what we write playbooks in. -
nameis the description of what this playbook does. -
hosts: aristawill execute this playbook only on the Arista network devices. -
gather_facts: falsethis 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.vlanstasks: - 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 fromarista.eos.vlanstojunipernetworks.junos.vlansit would work identically. This allows network engineers to focus on the network (e.g. VLAN configuration) versus the vendor syntax and implementation.
-
-
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=1indiciating that no changes were taken place.
-
Login to an Arista switch and verify the current VLAN configuration.
-
From the control node terminal, you can
ssh rtr2and typeenable$ ssh rtr2 Last login: Wed Sep 1 13:44:55 2021 from 44.192.105.112 rtr2>enable -
Use the command
show vlanto 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 vlanto 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).
- 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: mergedhas been switched togathered, theconfigis no longer needed since we are reading in the configuration (verus applying it to the network device), and we are using theregisterto save the output from the module into a variable namedvlan_config -
The second task is copying the
vlan_configvariable to a flat-file. The double currly brackets denotes that this is a variable. -
The
| to_nice_yamlis a filter, that will transform the JSON output (default) to YAML. -
The
playbook_dirandinventory_hostnameare special varaible also referred to as magic variables. Theplaybook_dirsimply means the directory we executed the playbook from, and theinventory_hostnameis the name of the device in our inventory. This means the file will be saved as~/network-workshop/rtr2_vlan.ymland~/network-workshop/rtr4_vlan.ymlfor the two arista devices.
-
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
-
Open the newly created files that
gatheredthe VLAN confgiuration from the Arista network devices. -
The two files were saved to
~/network-workshop/rtr2_vlan.ymland~/network-workshop/rtr4_vlan.ymlfor the two arista devices. -
Here is a screenshot:
- 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.
The finished Ansible Playbook is provided here for an answer key:
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.
Previous Exercise | Next Exercise
Click here to return to the Ansible Network Automation Workshop