OpenConfig. Part 2. New NETCONF modules in Ansible 2.6 (examples for Arista EOS, Cisco IOS XR and Nokia SR OS

Hello my friend,

While I’m still working on article for OpenConfig and BGP for automated and unified configuration of DC fabric, I’ve decided to show you operation of two new NETCONF modules, which are available in Ansible 2.6, which is the latest release for the time of writing.

Brief description

Frankly speaking, I planned to look at these modules later on, but my friend Nicola Arnoldi told me that there are some Red Hat videos, which explain how OpenConfig could be used in Ansible in more efficient way, so I decided to take a look on two new NETCONF modules, which are available in Asible 2.6:

• netconf_get
• netconf_rpc

In this blogpost, we’ll take a look capability of these modules to create data structure and collect variables (like IP addresses, interface names, etc) and operational data directly from the network elements.

What we are going to test?

We’ll test, how we can extract information (both configurational and operational data) in YANG data model through NETCONF and what to do further with this information.

Software version

The following infrastructure is used in my lab:

• CentOS 7 with python 2.7.
• Ansible 2.6.0
• Arista EOS 4.20.5F
• Nokia SR OS 16.0.R1
• Cisco IOS XR 6.1.2

See the previous article to get details how to build the lab

Topology

As physical topology we are taking our standard one, with all network elements (Nokia (Alcatel-Lucent) VSR, Arista vEOS and Cisco IOS XRv) connected to our management host with Linux CentOS 7

For the logical topology we take the one we have created in the previous lab:

Correspondingly the initial configuration for this lab is the one we have created in the previous one with the exception of Arista EOS based leaf vEOS2, as we haven’t managed to get it configured on NETCONF using OpenConfig data model, so we have configured it manually:

Module #1. Usage of netconf_get.

As you might guess from the name of the module, it’s used to send “get” RPC requests to the network device using desired XMLNS schema via NETCONF protocol. As a transport plugin it uses “netconf” , so the vendor must be supported. Let’s check. How it works.

1.1#. netconf_get and Nokia (Alcatel-Lucent) SR OS

If we look at the list of the authors of the module , we see that one of them is working in Red Hat and another is working in Nokia. That’s why we start investigations with Nokia (Alcatel-Lucent) SR OS

Following the same approach, we did in previous lab, we’ll create the Ansible structure with roles, so that we easily copy the same scripts between per vendor folders, if they really will work without modifications:

Before using Ansible playbook, I need to add “export ANSIBLE_HOST_KEY_CHECKING=False”, as somehow this parameter isn’t read properly from ansible.cfg.

Now it’s time to verify if our Ansible automation is working:

PLAY [nokia] *************************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [SR6]

TASK [nokia/130_lab : OPENCONFIG-INTERFACES // FETCHING INFORMATION THROUGH GET] *****************************************************************************
ok: [SR6]

TASK [nokia/130_lab : OPENCONFIG-INTERFACES // SAVING OUTPUT TO FILE] ****************************************************************************************
changed: [SR6]

PLAY [arista] ************************************************************************************************************************************************
skipping: no hosts matched

• Everything within “state” categories is coming from read-only fields and represent operational information. This information forms the basis of YANG-based telemetry
• Everything outside “state” are configurable parameters, which can be tuned

Looks amazing, isn’t it? For developers of the automation that is really great source of the information, I think.

1.2#. netconf_get and Cisco IOS XR

We just copy created task to appropriate folder in Cisco roles and that is it:

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [XR3]

TASK [cisco/130_lab : OPENCONFIG-INTERFACES // FETCHING INFORMATION THROUGH GET] *****************************************************************************
ok: [XR3]

TASK [cisco/130_lab : OPENCONFIG-INTERFACES // SAVING OUTPUT TO FILE] ****************************************************************************************
changed: [XR3]

PLAY [nokia] *************************************************************************************************************************************************
skipping: no hosts matched

PLAY [arista] ************************************************************************************************************************************************
skipping: no hosts matched

1.3#. netconf_get and Arista EOS

The successful operation of this “netconf_get” module for the Nokia (Alcatel-Lucent) and Cisco IOS XR gives me the feeling that for Arista EOS it also should work.

PLAY [nokia] *************************************************************************************************************************************************
skipping: no hosts matched

PLAY [arista] ************************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
fatal: [vEOS2]: FAILED! => {“msg”: ” [WARNING] Ansible is in a world writable directory (/home/aaa/ansible), ignoring it as an ansible.cfg source.\n{\”socket_path\”: \”/home/aaa/.ansible/pc/eee96979d7\”, \”exception\”: \”Traceback (most recent call last):\\n File \\\”/usr/bin/ansible-connection\\\”, line 87, in start\\n self.connection._connect()\\n File \\\”/usr/lib/python2.7/site-packages/ansible/plugins/connection/netconf.py\\\”, line 274, in _connect\\n raise AnsibleError(\\\”connection=netconf is not supported on {0}\\\”.format(network_os))\\nAnsibleError: connection=netconf is not supported on eos\\n\”, \”messages\”: [\”local domain socket does not exist, starting it\”, \”control socket path is /home/aaa/.ansible/pc/eee96979d7\”, \”\”], \”error\”: \”connection=netconf is not supported on eos\”}”}
to retry, use: –limit @/home/aaa/ansible/130_lab.retry

But I have found workaround for it. We need to modify “group_vars” in the following way:

PLAY [nokia] *************************************************************************************************************************************************
skipping: no hosts matched

PLAY [arista] ************************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [vEOS2]

TASK [arista/130_lab : OPENCONFIG-INTERFACES // FETCHING INFORMATION THROUGH GET] ****************************************************************************
ok: [vEOS2]

TASK [arista/130_lab : OPENCONFIG-INTERFACES // SAVING OUTPUT TO FILE] ***************************************************************************************
changed: [vEOS2]

So, if our goal is to collect some data, that this “netconf_get” module perfectly matches. If we want to do more, let’s go to the next one.

Module #2. Usage of netconf_rpc.

This module is written by the same author and uses the same transport netconf plugin based on ncclient. But it provides the possibility to send arbitrary RPC request and get proper response in case that network element has such capabilities.

2.1#. netconf_rpc and Cisco IOS XR

One of the useful requests, which might save a lot of time to you if proper implemented in vendor, is “get-schema”. In RFC 6022 there is some explanation, what this request is doing. In a short word, it extracts from the device content of particular supported YANG module, which can be converted in “.yang” model and read by “pyang”.

So, from Ansible prospective, we extend the playbook with tasks “main.yml” with 4 new tasks:

– name: ALL SCHEMAS // FETCHING INFORMATION THROUGH GET
netconf_get:
display: json
filter:
lock: never
register: list_of_schemas

– name: ALL SCHEMAS // SAVING OUTPUT TO FILE
copy:
content: “{{ list_of_schemas.output | to_nice_json }}”
dest: /tmp/{{ inventory_hostname }}_list_of_schemas.json

– name: OPENCONFIG-INTERFACES SCHEMA // FETCHING INFORMATION THROUGH GET-SCHEMA
netconf_rpc:
rpc: get-schema
xmlns: “urn:ietf:params:xml:ns:yang:ietf-netconf-monitoring”
content: “{‘identifier’: ‘openconfig-interfaces’}”
display: json
register: openconfig_interfaces

You see here 4 new entries:

• Two of them are using the same “copy” module to save the output
• One of them is using “netconf_get” module, which is already covered
• One of them is using new “netconf_rpc”

What is interesting, the content in “netconf_rpc” module could be filled in with either JSON or YAML structure, whatever you prefer more.

The information used in playbook comes from RFC 6022:

• One example there shows how to construct “get” message to obtain list of schemas
• Another example shows how to construct “get-schema” message to get the particular YANG module from this device

Let’s execute this playbook:

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [XR3]

TASK [cisco/130_lab : OPENCONFIG-INTERFACES // FETCHING INFORMATION THROUGH GET] *****************************************************************************
ok: [XR3]

TASK [cisco/130_lab : OPENCONFIG-INTERFACES // SAVING OUTPUT TO FILE] ****************************************************************************************
changed: [XR3]

TASK [cisco/130_lab : ALL SCHEMAS // FETCHING INFORMATION THROUGH GET] ***************************************************************************************
ok: [XR3]

TASK [cisco/130_lab : ALL SCHEMAS // SAVING OUTPUT TO FILE] **************************************************************************************************
changed: [XR3]

TASK [cisco/130_lab : OPENCONFIG-INTERFACES SCHEMA // FETCHING INFORMATION THROUGH GET-SCHEMA] ***************************************************************
ok: [XR3]

TASK [cisco/130_lab : OPENCONFIG-INTERFACES SCHEMA // SAVING OUTPUT TO FILE] *********************************************************************************
changed: [XR3]

PLAY [nokia] *************************************************************************************************************************************************
skipping: no hosts matched

PLAY [arista] ************************************************************************************************************************************************
skipping: no hosts matched

// namespace
namespace “http://openconfig.net/yang/interfaces”;

prefix “ocif”;

// import some basic types
import ietf-interfaces { prefix if; }
import ietf-yang-types { prefix yang; }
import openconfig-extensions { prefix oc-ext; }

// meta
organization “OpenConfig working group”;

contact
“OpenConfig working group
netopenconfig@googlegroups.com”;

description
“Model for managing network interfaces.

This model reuses data items defined in the IETF YANG model for
interfaces described by RFC 7223 with an alternate structure
(particularly for operational state data) and with additional
configuration items.”;

oc-ext:openconfig-version “0.2.0”;

revision “2015-11-20” {
description
“OpenConfig public release”;
reference “0.2.0”;
}

It looks amazing, isn’t it? Basically we can fetch all YANG modules from the device to reconstruct all YANG trees with dependencies, what in its turn could be used to construct proper configuration files and jijna2 templates.

2.2#. netconf_rpc and Arista EOS

In the same fashion we did previously, we just copy Ansible playbook with tasks from Cisco to Ansible folder:

PLAY [nokia] *************************************************************************************************************************************************
skipping: no hosts matched

PLAY [arista] ************************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [vEOS1]

TASK [arista/130_lab : OPENCONFIG-INTERFACES // FETCHING INFORMATION THROUGH GET] ****************************************************************************
ok: [vEOS1]

TASK [arista/130_lab : OPENCONFIG-INTERFACES // SAVING OUTPUT TO FILE] ***************************************************************************************
changed: [vEOS1]

TASK [arista/130_lab : ALL SCHEMAS // FETCHING INFORMATION THROUGH GET] **************************************************************************************
ok: [vEOS1]

TASK [arista/130_lab : ALL SCHEMAS // SAVING OUTPUT TO FILE] *************************************************************************************************
changed: [vEOS1]

TASK [arista/130_lab : OPENCONFIG-INTERFACES SCHEMA // FETCHING INFORMATION THROUGH GET-SCHEMA] **************************************************************
ok: [vEOS1]

TASK [arista/130_lab : OPENCONFIG-INTERFACES SCHEMA // SAVING OUTPUT TO FILE] ********************************************************************************
changed: [vEOS1]

This model reuses data items defined in the IETF YANG model for
interfaces described by RFC 7223 with an alternate structure
(particularly for operational state data) and with
additional configuration items.

Portions of this code were derived from IETF RFC 7223.
Please reproduce this note if possible.

2.3#. netconf_rpc and Nokia (Alcatel-Lucent) SR OS

Nokia (Alcatel-Lucent) SR OS comes third in a row for this “netconf_rpc” module, because in current release (SR OS 16.0.R1) not everything worls properly, but step by step. First of all we copy the Ansible playbook to folder with Nokia roles:

PLAY [nokia] *************************************************************************************************************************************************

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [SR6]

TASK [nokia/130_lab : OPENCONFIG-INTERFACES // FETCHING INFORMATION THROUGH GET] *****************************************************************************
ok: [SR6]

TASK [nokia/130_lab : OPENCONFIG-INTERFACES // SAVING OUTPUT TO FILE] ****************************************************************************************
changed: [SR6]

TASK [nokia/130_lab : ALL SCHEMAS // FETCHING INFORMATION THROUGH GET] ***************************************************************************************
ok: [SR6]

TASK [nokia/130_lab : ALL SCHEMAS // SAVING OUTPUT TO FILE] **************************************************************************************************
ok: [SR6]

TASK [nokia/130_lab : OPENCONFIG-INTERFACES SCHEMA // FETCHING INFORMATION THROUGH GET-SCHEMA] ***************************************************************
fatal: [SR6]: FAILED! => {“changed”: false, “msg”: “Element is not valid in the specified context.”}
to retry, use: –limit @/home/aaa/ansible/130_lab.retry

Nevertheless the list of supported schemas is fetched:

BONUS# Replacement of “netconf_config” by “netconf_rpc”

As I said in the beginning, “netconf_rpc” could be used to construct any RPC message. In previous article I have shown you the message flow, when we were testing OpenConfig messages. In Ansible playbook, we have used “netconf_config” module, which is created for configuration of the devices. But “netconf_rpc” also could be used, if we know the exact sequence of the actions, which must be done. For Nokia (Alcatel-Lucent) SR OS we have the following sequence:

• Lock the configuration
• Perform the changes
• Commit the changes
• Unlock the configuration
• Save the running configuration to start-up

Here is the example how it looks like in Ansible playbook using “netconf_rpc” module:

– name: config interface
netconf_rpc:
display: json
rpc: edit-config
content: |

loopback

loopback
softwareLoopback
true

0

Base

Base
DEFAULT_INSTANCE

loopback

loopback
loopback
0
IPV4
IPV6

– name: commit changes
netconf_rpc:
rpc: commit

– name: unlock candidate
netconf_rpc:
rpc: unlock
content: “{‘target’: {‘candidate’: None}}”

TASK [Gathering Facts] ***************************************************************************************************************************************
ok: [SR6]

TASK [lock candidate] ****************************************************************************************************************************************
ok: [SR6]

TASK [config interface] **************************************************************************************************************************************
ok: [SR6]

TASK [commit changes] ****************************************************************************************************************************************
ok: [SR6]

TASK [unlock candidate] **************************************************************************************************************************************
ok: [SR6]

TASK [copy running to startup] *******************************************************************************************************************************
ok: [SR6]

Playbooks from this lab: 130_lab.tar

Lessons learned

We are never done. We can stop developing something, just because we want to stop or don’t want to continue, but we can’t finish, because everything is done. Which is good in research areas.

Using “get” operation we have collected both operational and configuration data. This configuration data is exactly the structure of variables; we can use for device description.

Conclusion

With the overall trend for network automation and programmability all these YANG data models stars playing the crucial role, as they can really provide the possibility to automate multivendor environment in a predictable way. Now we have more information, which ultimately can be used for other activates, which are on our list, like using OpenConfig to create BGP fabric in data centre. Take care and good bye!

Support us

Support new interop and automation articles at karneliuk.com
EUR
I want to support with:
9.99 EUR4.99 EUR24.99 EUR49.99 EUR99.99 EUR199.99 EUR

P.S.

If you have further questions or you need help with your networks, I’m happy to assist you, just send me message. Also don’t forget to share the article on your social media, if you like it.

BR,

Anton Karneliuk