OpenConfig. Part 1. OpenConfig (w/o and w/ Ansible) for Arista EOS, Cisco IOS XR and Nokia SR OS

Hello my friend,

For long time I’ve been preparing to write this article and finally you are reading it. The topic is really hot as everything, which is named “open” today, becomes automatically fancy and widely discussed. What we will do today, we’ll explore the OpenConfig capabilities on Arista EOS, Cisco IOS XR and Nokia (Alcatel-Lucent) SR OS and will try to understand how much OpenConfig is really open.

Disclaimer

All the information is provided on “as-is” basis with the status of OpenConfig YANG modules in particular versions of Nokia VSR, Arista vEOS and Cisco IOS XRv. Different version might have different versions of OpenCofngi models and therefore structure of YANG model can be changed.

Brief description

The first time I we heard about OpenConfig project was not too long ago. Actually it was only on Cisco Live 2018. By that time, according to the website of OpenConfig, the project was roughly 3 years old. For me it’s good as it means that project has reached minimum level of maturity, so I’m able to create some scenarios using it. Or at least I hope so, as by the time I’ve started writing it, I haven’t implemented everything I am going to do.

So, what is OpenConfig? The official website gives us the following answer:

“OpenConfig is an informal working group of network operators sharing the goal of moving our networks toward a more dynamic, programmable infrastructure by adopting software-defined networking principles such as declarative configuration and model-driven management and operations; Our initial focus in OpenConfig is on compiling a consistent set of vendor-neutral data models (written in YANG) based on actual operational needs from use cases and requirements from multiple network operators”

Basically, It’s YANG data model, which should be the same across all vendors. Sounds really “open”. Some time ago, when we were reviewing NETCONF/YANG for Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, we explained that each and every vendor has its own YANG data model, what means that the automation tool, like Ansible, has to have per-vendor drivers, what is definitely requires a lot of developers’ efforts.

Just imagine, that you need to deploy automation only once, as all the vendors understand it in the same way.

That’s the goal of the OpenConfig initiative. Let’s take a look on the status of the OpenConfig YANG model now:

As you see, the current focus of the OpenConfig model lays on standard parameters in the configuration of the network devices: interfaces, ACLs, routing protocols and etc. Actually, most of the configuration regardless of the vendor is done across these parameters. Sure, deep tuning of the performance requires much more, but how often do we need such deep tuning? So. In my eyes, OpenConfig if implemented will ease the live of the network developers and operators a lot.

What we are going to test?

Initially I started writing the article about interfaces and BGP using OpenConfig, but it turned to be very long. That’s why this article is the first in the series about OpenConfig and is focused only on interfaces.

We will try make the following things in our article for 3 OSes (Arista EOS, Cisco IOS XR and Nokia SR OS):

• Get the configuration done in OpenConfig YANG model for interfaces
• Edit the desired configuration on OpenConfig YANG model for interfaces
• Create proper Ansible playbook for configuration of interfaces

The main reason, why I’m reading the configuration from the network device is that I learned that different virtual routers supports different versions of OpenConfig, hence there are some deviations in place in terms of syntax, so I need first of all to understand exact syntax of particular device.

Software version

The following infrastructure is used in my lab:

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

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

Just some weeks ago the new version of Ansible, which is 2.6.0 at the time of writing, was released. So I’m using it as there are some new modules for NETCONF, which might be useful for such automation.

Topology

The physical topology doesn’t vary from the something we have used previously, so it’s important that all our VNFs are somehow connected to management host:

We’ll use well known topology for data center fabric with 2 spines and 2 leafs with all vendors (Nokia VSR, Arista vEOS and Cisco XRv):

The initial configuration files just enable management access over SSH to devices over management interface: 128_config_initial_SR1 128_config_initial_vEOS2 128_config_initial_XR3 128_config_initial_XR4 128_config_initial_linux

How to read YANG model?

Let’s start with some recap about YANG data models. Some time ago, when we reviewed NETCONF/YANG for Cisco IOS XR, I have shared some information how to understand YANG structure. Here I’ll show more convenient way.

First of all, we need to download data models locally from GitHub repo of OpenConfig. Put it anywhere you like, just remember the exact path. I’ve put it into new folder:

Then I advise to install “pyang” tool, which is very easy and convenient to read YANG data:

After that is done, we can review any YANG data we have. To do that I issue the following command:

You can see many examples on “-f tree” in Internet, what helps to build that tree of YANG model. But there are only few examples on “-p xxx”, which used to set the path to look for dependencies in other modules. If you don’t configure path, you might see the following error:

After we have understood, how to treat the OpenConfig YANG data models, we can go further.

Which transport to use?

OpenConfig isn’t bounded to any particular transport mechanism according to the official website. So it can be used over:

• NETCONF
• RESTCONF
• gNMI (gRPC Network Management Interface)

In this article we will use NETCONF, as several time previously, so that we have consistent view on network management techniques.

OpenConfig and Cisco IOS XR

I will start with OpenConfig explanation with Cisco IOS XR. The reason why I’m doing it in this way is that Cisco IOS XR has some examples and demos in the Internet, which I used to get to know OpenConfig. So, for me it was essentially to start with something familiar.

#1. Cisco IOS XR. Enabling OpenConfig

There is no specific configuration for OpenConfig on Cisco IOS XR comparing to ordinary NETCONF, so we just enable NETCONF as usual:

When this configuration is done, let’s test, what we see in NETCONF call flow:

Please login with any configured user/password, or cisco/cisco

urn:ietf:params:netconf:base:1.1
urn:ietf:params:netconf:capability:candidate:1.0
urn:ietf:params:netconf:capability:rollback-on-error:1.0
urn:ietf:params:netconf:capability:validate:1.1
urn:ietf:params:netconf:capability:confirmed-commit:1.1
http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-lib-cfg?module=Cisco-IOS-XR-aaa-lib-cfg&revision=2015-11-09
!
! Output ommited
!
http://openconfig.net/yang/bgp-multiprotocol?module=openconfig-bgp-multiprotocol&revision=2015-10-09
http://openconfig.net/yang/bgp-operational?module=openconfig-bgp-operational&revision=2015-10-09
http://openconfig.net/yang/bgp-policy?module=openconfig-bgp-policy&revision=2015-10-09&deviation=cisco-xr-bgp-policy-deviations
http://openconfig.net/yang/bgp-types?module=openconfig-bgp-types&revision=2015-05-15
http://openconfig.net/yang/bgp?module=openconfig-bgp&revision=2015-10-09&deviation=cisco-xr-bgp-deviations
http://openconfig.net/yang/openconfig-ext?module=openconfig-extensions&revision=2015-10-09
http://openconfig.net/yang/interface/aggregate?module=openconfig-if-aggregate&revision=2015-11-20&deviation=cisco-xr-openconfig-if-aggregate-deviations
http://openconfig.net/yang/interfaces/ethernet?module=openconfig-if-ethernet&revision=2015-11-20&deviation=cisco-xr-openconfig-if-ethernet-deviations
http://openconfig.net/yang/interfaces/ip?module=openconfig-if-ip&revision=2015-11-20&deviation=cisco-xr-openconfig-if-ip-deviations
http://openconfig.net/yang/interfaces?module=openconfig-interfaces&revision=2015-11-20&deviation=cisco-xr-openconfig-interfaces-deviations
http://openconfig.net/yang/ldp?module=openconfig-mpls-ldp&revision=2015-11-05
http://openconfig.net/yang/rsvp?module=openconfig-mpls-rsvp&revision=2015-11-05
http://openconfig.net/yang/sr?module=openconfig-mpls-sr&revision=2015-11-05
http://openconfig.net/yang/mpls-types?module=openconfig-mpls-types&revision=2015-11-05
http://openconfig.net/yang/mpls?module=openconfig-mpls&revision=2015-11-05&deviation=cisco-xr-openconfig-mpls-deviations
http://openconfig.net/yang/policy-types?module=openconfig-policy-types&revision=2015-10-09
http://openconfig.net/yang/routing-policy?module=openconfig-routing-policy&revision=2015-10-09&deviation=cisco-xr-routing-policy-deviations
http://openconfig.net/yang/telemetry?module=openconfig-telemetry&revision=2016-02-04&deviation=cisco-xr-openconfig-telemetry-deviations
http://openconfig.net/yang/openconfig-types?module=openconfig-types&revision=2015-10-09
http://openconfig.net/yang/vlan?module=openconfig-vlan&revision=2015-10-09&deviation=cisco-xr-openconfig-vlan-deviations

1743594516

I’ve reduced the output only to filter supported OpenConfig modules, so that I can find, which modules I should use in automation scripts using CLI or Ansible.

From this time, OpenConfig over NETCONF is ready to rock on Cisco IOS XR.

#2. Cisco IOS XR. Get the interface configuration using OpenConfig

Here we start with basic configuration on Cisco IOS XR to create one sub interface and loopback interface to get understanding on how would it look like on OpenConfig:

After we have implemented this configuration, we briefly check, what do we have on Cisco IOS XR router XR4 configured:

Now, we see in the NETCONF session, what is configured in OpenConfig YANG model. To do this we send RPC request with “get-config” instruction through the opened NETCONF over SSH session:

As response we get extensive RPC reply:

Loopback0

Loopback0
idx:softwareLoopback
true

10.0.0.44

 

10.0.0.44 32

fc00::10:0:0:44

 

fc00::10:0:0:44 128

MgmtEth0/0/CPU0/0

MgmtEth0/0/CPU0/0
idx:ethernetCsmacd
false

false

GigabitEthernet0/0/0/0

GigabitEthernet0/0/0/0
idx:ethernetCsmacd
true

false

0
0

0
0

34

34
GigabitEthernet0/0/0/0.34
true

false

fc00::10:33:44:44

 

fc00::10:33:44:44 112

10.33.44.44

 

10.33.44.44 24

34

999

999
GigabitEthernet0/0/0/0.999
true

false

192.168.1.112

 

192.168.1.112 24

999

Remember, we have explained the framing of the message previously

In this RPC reply we see all the parameters, which is related to the interfaces we have created including management interface, which is related to another VRF though.

#3. Cisco IOS XR. Edit the interface configuration using OpenConfig

Now it’s time to create our own sub-interface and loopback interface in order to understand, if we understand this OpenConfig YANG data model for interface correct. We will create the “Loopback 1” with another IP address and new sub-interface ”GigabitEthernet0/0/0/0.13” using “edit-config” message in OpenConfg format:

rollback-on-error

Loopback1

Loopback1
idx:softwareLoopback
true

10.0.1.44

 

10.0.1.44 32

fc00::10:0:1:44

 

fc00::10:0:1:44 128

GigabitEthernet0/0/0/0

GigabitEthernet0/0/0/0
idx:ethernetCsmacd
true

false

14

14
GigabitEthernet0/0/0/0.14
true

false

fc00::10:11:44:44

 

fc00::10:11:44:44 112

10.11.44.44

 

10.11.44.44 24

14

If everything was entered correctly, we will get corresponding “OK”:

Don’t forget, we deal with Cisco IOS XR, so we need to commit configuration using corresponding “commit” message:

And we receive OK again:

So far the trace looks nice, that’s why we are checking the output of “show interface” at Cisco IOS XR both for IPv4 and IPv6:

Both newly created interfaces are up and running so it means that our OpenConfig understanding is correct. Let’s move further to get working Ansible playbook for interface configuration.

#4. Cisco IOS XR. Ansible for OpenConfig with Cisco

Based on the manually creation of NETCONF “edit-config” requests using OpenConfig YANG data model, we’ll create Ansible playbook to make configuration of interfaces using this OpenConfig YANG model.

OpenConfig is claimed to be vendor-agnostic, so I hope that I will need to create the script only once and all the vendors will be managed using it. Nevertheless, I will create some roles in Ansible so that it is easier to manage deviations per vendor if any arise. The structure of Ansible playbooks and roles is similar to what we did recently for Arista automation:

Here is connectivity parameters:

The structure of the variables follows the OpenConfig YANG data model.

There is single change: there is no possibility to have variable name, which contains symbol “-“, that’s why it’s replaced with “_”.

Here is the example of variables for spine switch XR3 based on Cisco IOS XR:

If you look carefully, you will see that this files exactly follows OpenConfig YANG data model we have seen previously in “get-config” RPC reply over NETCONF.

In the same way we create file with variable for XR4. It isn’t shown here, but will be listed in files as usually.

The next step in our Ansible-based automation is to create proper jinja2 template so that config is created automatically. As you see in variables, we are using dictionaries a lot to simplify template:

{% for iface in node.interfaces %}

{{ iface.name }}

{{ iface.name }}
idx:{{ iface.type }}
{{ iface.enabled|lower }}

{% if iface.subinterfaces is defined %}

{% for siface in iface.subinterfaces %}

{{ siface.index }}
{% if siface.index != 0 %}

{{ siface.index }}
{{ iface.name }}.{{ siface.index }}
{{ siface.enabled|lower }}

{% endif %}
{% if siface.ipv4 is defined %}

{{ addr.ip }}

 

{{ addr.ip }} {{ addr.prefix_length }}

{% endfor %}

{% endif %}
{% if siface.ipv6 is defined %}

{% for addr in siface.ipv6.address %}

{{ addr.ip }}

 

{{ addr.ip }} {{ addr.prefix_length }}

{% endif %}
{% if siface.vlan is defined %}

{{ siface.vlan.vlan_id }}

{% endif %}

{% endfor %}

{% endif %}

{% endfor %}

The last but not least point is to create the file with tasks. To be honest, I think, it’s the easiest step as it’s very straightforward:

The second task in play isn’t necessary and is used primary for debugging in order we can see how exactly the ”config” part of NETCONF “edit-config” message looks like.

Well, there is one more thing we need to do. We need to create general Ansible playbook, which will call roles:

Up to now we have created everything necessary to automate deployment of spine switches based on Cisco IOS XR.

Before we try it, I will remove all created interfaces and will leave only initial config on Cisco IOS XR based spines XR3 and XR4:

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

TASK [cisco/128_lab : IMPORTING VARS] *********************************************************************
ok: [XR3]
ok: [XR4]

TASK [cisco/128_lab : CREATING TEMPORARY FILE TO MANUALLY CHECK THAT EDIT-CONFIG IS CORRECT] **************
ok: [XR4]
ok: [XR3]

TASK [cisco/128_lab : OPENCOFNIG // CONFIGURING INTERFACES] ***********************************************
changed: [XR4]
changed: [XR3]

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

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

Looks good. Let’s double check on CLI:

Cisco is done. So, we have deployed configuration of the interfaces using OpenConfig YANG data model over NETCONF transport. Let’s check how other vendors behave. Hypothetically there should be no difference. Do you believe? 🙂

OpenConfig and Nokia SR OS

Nokia has introduced support of OpenConfig YANG data models only in the latest version of its SR OS, which is Nokia (Alcatel-Lucent) SR OS 16.0.R1 for the time of the writing. What is interesting, Nokia VSR doesn’t support it yet, but rather physical devices (like Nokia SR 7750/7950 and so on) or Nokia vSIM, which emulates HW of real devices. That’s why we change the initial XML file, we have used all time long (link). The change impacts only one line, which is probably the most important:

Usage of this line in initial XML descriptor of VM for KVM assures we launch vSIM emulating this particular HW instead of VSR.

When we launch VM and provision the card and MDA, we should see the following outputs, if everything is done correctly. The chassis is SR-1:

The following card is installed in the cassis:

And the following MDA is there:

Such Nokia (Alcatel-Lucent) vSIM supports OpenConfig, so we start with the core topic of the article.

Information about MD-CLI, how to configure and to use it you can find in separate article.

#1. Nokia SR OS. Enabling OpenConfig

We have explained previously how to enable NETCONF in Nokia (Alcatel-Lucent) VSR / SR 7750, but there are some changes in SR OS 16.0.R1, so we’ll cover the full configuration:

Only configuration related to NETCONF and OpenConfig is shown.

Comparing to previous example, here we have 2 major differences:

• It’s done in MD-CLI mode.
• Set of YANG modules are enabled explicitly.

So we need explicitly enable OpenConfig YANG model in order we can use it. Let’s connect to our Nokia SROS based leaf SR6:

urn:ietf:params:netconf:base:1.0
urn:ietf:params:netconf:base:1.1
urn:ietf:params:netconf:capability:candidate:1.0
urn:ietf:params:netconf:capability:confirmed-commit:1.1
urn:ietf:params:netconf:capability:notification:1.0
urn:ietf:params:netconf:capability:interleave:1.0
urn:ietf:params:netconf:capability:validate:1.0
urn:ietf:params:netconf:capability:validate:1.1
urn:ietf:params:netconf:capability:startup:1.0
urn:ietf:params:netconf:capability:url:1.0?scheme=ftp,tftp,file
urn:ietf:params:netconf:capability:with-defaults:1.0?basic-mode=explicit&also-supported=report-all
…
http://openconfig.net/yang/acl?module=openconfig-acl&revision=2016-01-22
http://openconfig.net/yang/bgp?module=openconfig-bgp&revision=2016-03-31
http://openconfig.net/yang/bgp-policy?module=openconfig-bgp-policy&revision=2016-06-21
http://openconfig.net/yang/bgp-types?module=openconfig-bgp-types&revision=2016-06-21
http://openconfig.net/yang/openconfig-ext?module=openconfig-extensions&revision=2015-10-05
http://openconfig.net/yang/interfaces/aggregate?module=openconfig-if-aggregate&revision=2016-12-22
http://openconfig.net/yang/interfaces/ethernet?module=openconfig-if-ethernet&revision=2016-12-22
http://openconfig.net/yang/interfaces/ip?module=openconfig-if-ip&revision=2016-12-22
http://openconfig.net/yang/interfaces/ip-ext?module=openconfig-if-ip-ext&revision=2016-12-22
http://openconfig.net/yang/types/inet?module=openconfig-inet-types&revision=2017-01-26
http://openconfig.net/yang/interfaces?module=openconfig-interfaces&revision=2016-12-22
http://openconfig.net/yang/openconfig-isis?module=openconfig-isis&revision=2016-10-18
http://openconfig.net/yang/isis-lsdb-types?module=openconfig-isis-lsdb-types&revision=2016-10-18
http://openconfig.net/yang/openconfig-isis-policy?module=openconfig-isis-policy&revision=2016-10-18
http://openconfig.net/yang/isis-types?module=openconfig-isis-types&revision=2016-10-18
http://openconfig.net/yang/lacp?module=openconfig-lacp&revision=2016-05-26
http://openconfig.net/yang/lldp?module=openconfig-lldp&revision=2016-05-16
http://openconfig.net/yang/lldp/types?module=openconfig-lldp-types&revision=2016-05-16
http://openconfig.net/yang/local-routing?module=openconfig-local-routing&revision=2016-05-11
http://openconfig.net/yang/mpls?module=openconfig-mpls&revision=2016-08-08
http://openconfig.net/yang/rsvp?module=openconfig-mpls-rsvp&revision=2016-08-08
http://openconfig.net/yang/mpls-sr?module=openconfig-mpls-sr&revision=2016-08-08
http://openconfig.net/yang/mpls-types?module=openconfig-mpls-types&revision=2016-08-08
http://openconfig.net/yang/network-instance?module=openconfig-network-instance&revision=2015-10-18
http://openconfig.net/yang/network-instance-types?module=openconfig-network-instance-types&revision=2015-10-18
http://openconfig.net/yang/header-fields?module=openconfig-packet-match&revision=2016-04-27
http://openconfig.net/yang/packet-match-types?module=openconfig-packet-match-types&revision=2016-04-27
http://openconfig.net/yang/policy-types?module=openconfig-policy-types&revision=2016-05-12
http://openconfig.net/yang/relay-agent?module=openconfig-relay-agent&revision=2016-05-16
http://openconfig.net/yang/routing-policy?module=openconfig-routing-policy&revision=2016-05-12
http://openconfig.net/yang/rsvp-sr-ext?module=openconfig-rsvp-sr-ext&revision=2017-03-06
http://openconfig.net/yang/openconfig-types?module=openconfig-types&revision=2016-05-31
http://openconfig.net/yang/vlan?module=openconfig-vlan&revision=2016-05-26
http://openconfig.net/yang/vlan-types?module=openconfig-vlan-types&revision=2016-05-26
http://openconfig.net/yang/types/yang?module=openconfig-yang-types&revision=2017-01-26
urn:nokia.com:sros:ns:yang:sr:openconfig_acl_deviations?module=nokia-sr-openconfig-acl-deviations&revision=2016-01-22
urn:nokia.com:sros:ns:yang:sr:openconfig_bgp_policy_deviations?module=nokia-sr-openconfig-bgp-policy-deviations&revision=2016-06-21
urn:nokia.com:sros:ns:yang:sr:openconfig_bgp_deviations?module=nokia-sr-openconfig-bgp-deviations&revision=2016-03-31
urn:nokia.com:sros:ns:yang:sr:openconfig_if_aggregate_deviations?module=nokia-sr-openconfig-if-aggregate-deviations&revision=2016-12-22
urn:nokia.com:sros:ns:yang:sr:openconfig_if_ethernet_deviations?module=nokia-sr-openconfig-if-ethernet-deviations&revision=2016-12-22
urn:nokia.com:sros:ns:yang:sr:openconfig_if_ip_ext_deviations?module=nokia-sr-openconfig-if-ip-ext-deviations&revision=2016-12-22
urn:nokia.com:sros:ns:yang:sr:openconfig_if_ip_deviations?module=nokia-sr-openconfig-if-ip-deviations&revision=2016-12-22
urn:nokia.com:sros:ns:yang:sr:openconfig_interfaces_deviations?module=nokia-sr-openconfig-interfaces-deviations&revision=2016-12-22
urn:nokia.com:sros:ns:yang:sr:openconfig_isis_policy_deviations?module=nokia-sr-openconfig-isis-policy-deviations&revision=2016-10-18
urn:nokia.com:sros:ns:yang:sr:openconfig_lldp_deviations?module=nokia-sr-openconfig-lldp-deviations&revision=2016-05-16
urn:nokia.com:sros:ns:yang:sr:openconfig_mpls_deviations?module=nokia-sr-openconfig-mpls-deviations&revision=2016-08-08
urn:nokia.com:sros:ns:yang:sr:openconfig_network_instance_deviations?module=nokia-sr-openconfig-network-instance-deviations&revision=2015-10-18
urn:nokia.com:sros:ns:yang:sr:openconfig_relay_agent_deviations?module=nokia-sr-openconfig-relay-agent-deviations&revision=2016-05-16
urn:nokia.com:sros:ns:yang:sr:openconfig_routing_policy_deviations?module=nokia-sr-openconfig-routing-policy-deviations&revision=2016-05-12
urn:nokia.com:sros:ns:yang:sr:openconfig_vlan_deviations?module=nokia-sr-openconfig-vlan-deviations&revision=2016-05-26

8

As I’ve enabled all YANG modules, the output was very long, that’s why only OpenConfig related capabilities are shown.

#2. Nokia SR OS. Get the interface configuration using OpenConfig

Following the same approach we’ve done for Cisco, we’ll configure some interfaces in OpenConfig model.

In MD-CLI Nokia SR OS has dedicated context for OpenConfig configuration.

To make story a shorter, I will show the configuration of one interface:

As you see, in Nokia we need to define interfaces in two contexts: interfaces and network-instances, what is different to Cisco implementation. The should be or will be released some documentation for OpenConfig in Nokia (Alcatel-Lucent) SR OS, but as usually I got to it just trying to bring it working using “plug and pray” approach.

That’s how the interfaces is shown in CLI:

As you might spot, we don’t define the name in this configuration. It’s created automatically based on the name of port and subinterface’s index. Now we check how that looks in NETCONF:

1/1/c1/1

1/1/c1/1
ethernetCsmacd
true

13

13
true

10.11.33.11

 

10.11.33.11 24

fc00::10:11:33:11

 

fc00::10:11:33:11 112

13

]]>]]>

Base

]]>]]>

Base

1/1/c1/1.13

1/1/c1/1.13
1/1/c1/1
13
IPV4
IPV6

The output of “get-config” message looks quite similar to what we have seen in Cisco IOS XR, but for sure it isn’t identical. Even if we omit necessity to created additional network-instance context, we need to tune initial jijna2 template.

That’s what we are going to do.

#3. Nokia SR OS. Edit the interface configuration using OpenConfig

The idea of testing proper “edit-config” messages is explained earlier in Cisco part, so you can follow the logic easily.

We’ll try to create system loopback interface logic, based on the types we can read in OpenConfig YANG models or what we have seen in Cisco part.

Don’t forget to commit changes!

system

system
softwareLoopback
true

0

1 2	<code lang="xml"><br> 10.0.0.11

 

1	<code lang="xml">

10.0.0.11
32

1

<br>

1

fc00::10:0:0:11

 

fc00::10:0:0:11 128

]]>]]>

Base

Base
DEFAULT_INSTANCE

system

system
system
0
IPV4
IPV6

]]>]]>

]]>]]>

]]>]]>

After we have sent the proper “edit-config” messages and committed configuration over NETCONF, we can verify, what we see in CLI:

As interfaces is properly reflected, it means that our understanding of OpenConfig YANG in Nokia (Alcate-Lucent) SR OS is correct and we can proceed with Ansible

#4. Nokia SR OS. Ansible for OpenConfig with Cisco

The data structure is fully identical to one we have in case of Cisco. Moreover, we copy already created files for Cisco in Nokia roles:

This is data structure of Ansible playbook:

Just in the same way as creating Ansible playbook for automating OpenConfig operation with Cisco IOS XR, we start with some authentication data, which will be used:

Then we go to variable. As you see, there is no changes comparing to variables for Cisco:

To be honest, I find this part particulary important. The data model is the same for all elements, thanks OpenConfig! Only such approach can create truly automation.

The next point in creating proper playbook is tuning the Jinja2 template for interfaces:

{% for iface in node.interfaces %}

{{ iface.name }}

{{ iface.name }}
{% if ansible_network_os == “iosxr” %}
idx:{{ iface.type }}
{% else %}
{{ iface.type }}
{% endif %}
{{ iface.enabled|lower }}

{% if iface.subinterfaces is defined %}

{% for siface in iface.subinterfaces %}

{{ siface.index }}
{% if siface.index != 0 %}

{{ siface.index }}
{% if ansible_network_os == “iosxr” %}
{{ iface.name }}.{{ siface.index }}
{% endif %}
{{ siface.enabled|lower }}

{% endif %}
{% if siface.ipv4 is defined %}
{% if ansible_network_os != “sros” %}

{% else %}

{{ addr.ip }}

 

{{ addr.ip }} {{ addr.prefix_length }}

{% endfor %}
{% if ansible_network_os != “iosxr” %}
{% endif %}

{% endif %}
{% if siface.ipv6 is defined %}
{% if ansible_network_os != “sros” %}

{% else %}

{% endif %}
{% if ansible_network_os != “iosxr” %}
{% endif %}
{% for addr in siface.ipv6.address %}

{{ addr.ip }}

 

{{ addr.ip }} {{ addr.prefix_length }}

{% endif %}
{% if siface.vlan is defined %}
{% if ansible_network_os != “sros” %}

{% else %}

{% endif %}

{{ siface.vlan.vlan_id }}

{% endif %}

{% endfor %}

{% endif %}

{% endfor %}

It became a bit more complicated comparing to initial one. The complications come from the fact that we need to take into account particular syntax per vendor. For instance, for IP address configuration we put:

• For Cisco: <ipv4 xmlns=”http://openconfig.net/yang/interfaces/ip”>
• For Nokia: <ipv4>

Additionally, Nokia put all kind of IP addresses into <addresses> group, whereas there is no such group in Cisco IOS XR.

But again, the syntax is relevant only for Cisco IOS XRv 6.1.2 and Nokia SR OS 16.0.R1. For other versions of NOSes it might changes.

As we have additional configuration in step in Nokia SR OS, we create new template:

Base

Base
DEFAULT_INSTANCE

{% for iface in node.interfaces %}
{% for siface in iface.subinterfaces %}

{% if iface.name == “system” %}
{{ iface.name }}
{% else %}
{{ iface.name }}.{{ siface.index }}
{% endif %}

{% if iface.name == “system” %}
{{ iface.name }}
{% else %}
{{ iface.name }}.{{ siface.index }}
{% endif %}
{{ iface.name }}
{{ siface.index }}
{% if siface.ipv4 is defined %}
IPV4
{% endif %}
{% if siface.ipv6 is defined %}
IPV6
{% endif %}

{% endfor %}
{% endfor %}

Now we need to extend the Ansible playbook with tasks:

– name: OPENCOFNIG // CONFIGURING INTERFACES I
netconf_config:
host: “{{ inventory_hostname }}”
username: “{{ ansible_user }}”
password: “{{ ansible_pass }}”
port: 830
hostkey_verify: false
look_for_keys: false
save: yes
xml: “{{ lookup (‘template’, ‘interfaces.j2’) }}”

– name: CREATING TEMPORARY FILE TO MANUALLY CHECK THAT EDIT-CONFIG IS CORRECT II
template:
src: network_instance_interfaces.j2
dest: /tmp/oc_{{ inventory_hostname }}_ni.conf
mode: 0755
when: ansible_network_os == “sros”

If you don’t need to debug the messages, just remove 2^nd and 4^th task. As you see, we add the condition to check for “ansible_network_os” to play this part of the playbook only for Nokia (Alcatel-Lucent) SR OS. It won’t be played for Cisco IOS XR.

So, automation using Ansible for interfaces configuration in Nokia (Alcatel-Lucent) SR OS using OpenConfig YANG data models through NETCONF is ready. So we can test it:

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

TASK [Gathering Facts] ************************************************************************************
ok: [SR2]
ok: [SR1]
ok: [SR6]
ok: [VSR6]

TASK [nokia/128_lab : IMPORTING VARS] *********************************************************************
fatal: [VSR6]: FAILED!
fatal: [SR1]: FAILED!
fatal: [SR2]: FAILED!
ok: [SR6]

TASK [nokia/128_lab : CREATING TEMPORARY FILE TO MANUALLY CHECK THAT EDIT-CONFIG IS CORRECT I] ************
ok: [SR6]

TASK [nokia/128_lab : OPENCOFNIG // CONFIGURING INTERFACES I] *********************************************
changed: [SR6]

TASK [nokia/128_lab : CREATING TEMPORARY FILE TO MANUALLY CHECK THAT EDIT-CONFIG IS CORRECT II] ***********
ok: [SR6]

TASK [nokia/128_lab : OPENCOFNIG // CONFIGURING INTERFACES II] ********************************************
changed: [SR6]

PLAY [arista] *********************************************************************************************
skipping: no hosts matched
to retry, use: –limit @/home/aaa/ansible/128_lab.retry

Only one of 4 VSRs are working, because I haven’t created files with variables for them. The verification shows that all the interfaces we have mentioned in variables are up and running:

2 out of 3 vendors are covered for OpenConfig YANG data models over NETCONF. There only one to go.

OpenConfig and Arista EOS

According to the information I’ve found in the Internet, OpenConfig in Arista EOS is supported starting EOS 4.20.2F, but that time there were a lot of limitations in terms of supported modules and operations (much more read-only rather than read-write). The actual release notes for version 4.20.5F provides much more OpenConfig capabilities, though the latter link requires authentication, so make sure you have registered at Arista website.

#1. Arista EOS. Enabling OpenConfig

According to the links provided above, the configuration of NETCONF at Arista EOS is quite straightforward and requires only configuration of corresponding management API:

The strange thing is that the standard port 830 doesn’t work, and any other arbitrary port doesn’t work either. How did I check that? I’m truing to connect to SSH through console in Linux, as I did both for Cisco IOS XR and Nokia (Alcatel-Lucent) SR OS:

But it hangs and become time out after some time. In order to connect for NETCONF, I need to remove “-p 830” so that I’m connected on standard SSH port 22:

I don’t know, if it’s problem only of Arista vEOS, as I explained previously about VXLAN L3 VNI (link), or Arista EOS in general is affected. I hope colleagues from Arista could clarify this problem.

Also there is interesting fact that Arista sends all capabilities in a single line without “/n” split between lines containing different capabilities, like Nokia and Cisco does.

#2. Arista EOS. Get the interface configuration using OpenConfig

Just in the same fashion we did two times, let’s create two interfaces from CLI to verify the output of NETCONF RPC reply message in OpenConfig YANG data model for interfaces:

Brief check that interfaces are up and running at Arista EOS based leaf vEOS2:

Now we can collect info through NETCONF using “edit-config” message:

#23
true
#96
300
#12
0
#24
Management1
#27
ethernetCsmacd
#9

#175
false
#28
false
#34
false
#15

#44
00:00:00:00:00:00
#38
SPEED_UNKNOWN
#100
false
#9

#11

#45
0
#24
0
#9

192.168.44.82
#30
192.168.44.82
#33 24 #9

 

#10

#12
#32
false
#15
1500
#9

#7

#87
false
#15
1500
#9

#7

#15

#16

#12

#33
Ethernet3
#35

#23
true
#96
300
#12
0
#22
Ethernet3
#27
ethernetCsmacd
#9

#175
false
#28
false
#34
false
#15

#44
00:00:00:00:00:00
#38 SPEED_UNKNOWN #100
false
#9

#11

#45
0
#24
0
#9

#87
false
#15
1500
#9

#7

#87
false
#15
1500
#9

#7

#15

#16

#12

#33
Ethernet2
#35

#23
true
#96
300
#12
0
#22
Ethernet2
#27
ethernetCsmacd
#9

#175
false
#28
false
#34
false
#15

#44
00:00:00:00:00:00
#38 SPEED_UNKNOWN #100
false
#9

#11

#45
0
#24
0
#9

#87
false
#15
1500
#9

#7

#87
false
#15
1500
#9

#7

#15

#16

#12

#33
Ethernet1
#35

#23
true
#96
300
#12
0
#22
Ethernet1
#27
ethernetCsmacd
#9

#175
false
#28
false
#34
false
#15

#44
00:00:00:00:00:00
#38 SPEED_UNKNOWN #100
false
#9

#11

#45
0
#24
0
#9

#66
#12
#31
true
#15
1500
#9

#7

#87
false
#15
1500
#9

#7

#15

#31
23
#35

#23
true
#17
23
#9

#95

10.22.33.22
#28
10.22.33.22
#33 24 #9

 

#10

#12
#31
true
#15
1500
#9

#7

#101

fc00::10:22:33:22
#34
fc00::10:22:33:22
#34 112 #9

 

#10

#15

#16

#12

#13

#19

Well, output in Arista vEOS is a bit more difficult to read. We should remove all “#xx” framing symbols and add appropriate “/n” splitters to make it readable by human. I don’t provide the formatted output as it’s quite long (and in A4 pages’ size I’m already close to 60 pages, so I’m not sure you are still reading this article).

There are a couple of points we can spot in the output above:

• It’s more similar to Cisco in terms of naming additional schemes, like <ipv4 xmlns=”http://openconfig.net/yang/interfaces/ip”>
• It mixes Arista-proprietary parameters together with OpenConfig, like adding <sfp-1000base-t xmlns=”http://arista.com/yang/openconfig/interfaces/augments”>
• It DOESN’T contain output of interface Loopback0.

Regarding the last point, again I don’t know, if it’s the problem of Arista EOS in general or Arista vEOS in particular.

#3. Arista EOS. Edit the interface configuration using OpenConfig

As I have configured manually only very small subset of parameters, like IPv4/IPv6 addresses and VLANs, I hope it would be enough to configure them over NETCONF using OpenConfig YANG model as well, without providing rest of parameters. Otherwise we again are going away from truly automation using single data model for devices and single Jinja2 template for NETCONF.

Just in the same way, we’ve done for Nokia (Alcatel-Lucent) SR OS and Cisco IOS XR, we will configure additional subinterface on Arista EOS based leaf vEOS2:

Ethernet1

Ethernet1
ethernetCsmacd
true

23

23
true

1 2	<code lang="xml"><br> 10.22.33.22

 

1	<code lang="xml">

10.22.33.22
24

1

<br>

1

fc00::10:22:33:22

 

fc00::10:22:33:22 112

23

24

24
true

10.22.44.22

 

10.22.44.22 24

fc00::10:22:44:22

 

fc00::10:22:44:22 112

24

##

And here we come to the point that no changes are applied despite “OK” response from vEOS2 and positive information in logs:

If we take a look into configuration of Arista vEOS, there are no changes:

I have done some researches in one or another direction, but still I haven’t succeeded to make it working for Arista EOS. I hope, colleagues from Arista could provide some feedback.

#4. Arista EOS. Ansible for OpenConfig with Cisco

From the automation point of view there is no difference comparing to previous two examples:

So we just copy, what we have done in Nokia part to Arista:

Now, as previously, I guide you through key files. This time I do it without further explanation, as I did it twice already.

If you still have questions, refer to previous Cisco IOS XR or Nokia (Alcatel-Lucent) SR OS examples.

Number one is the authentication data:

Number two is the per node parameters:

Number three is the Jinja2 template for interfaces:

{% for iface in node.interfaces %}

{{ iface.name }}

{{ iface.name }}
{% if ansible_network_os == “iosxr” %}
idx:{{ iface.type }}
{% else %}
{{ iface.type }}
{% endif %}
{{ iface.enabled|lower }}

{% if iface.subinterfaces is defined %}

{% for siface in iface.subinterfaces %}

{{ siface.index }}
{% if siface.index != 0 %}

{{ siface.index }}
{% if ansible_network_os == “iosxr” %}
{{ iface.name }}.{{ siface.index }}
{% endif %}
{{ siface.enabled|lower }}

{% endif %}
{% if siface.ipv4 is defined %}
{% if ansible_network_os != “sros” %}

{% else %}

{{ addr.ip }}

 

{{ addr.ip }} {{ addr.prefix_length }}

{% endfor %}
{% if ansible_network_os != “iosxr” %}
{% endif %}

{% endif %}
{% if siface.ipv6 is defined %}
{% if ansible_network_os != “sros” %}

{% else %}

{% endif %}
{% if ansible_network_os != “iosxr” %}
{% endif %}
{% for addr in siface.ipv6.address %}

{{ addr.ip }}

 

{{ addr.ip }} {{ addr.prefix_length }}

{% endif %}
{% if siface.vlan is defined %}
{% if ansible_network_os != “sros” %}

{% else %}

{% endif %}

{{ siface.vlan.vlan_id }}

{% endif %}

{% endfor %}

{% endif %}

{% endfor %}

Point out there is no single change comparing to one we did for Nokia!

Number four is the playbook with tasks:

– name: OPENCOFNIG // CONFIGURING INTERFACES I
netconf_config:
host: “{{ inventory_hostname }}”
username: “{{ ansible_user }}”
password: “{{ ansible_ssh_pass }}”
port: 22
hostkey_verify: false
look_for_keys: false
datastore: running
xml: “{{ lookup (‘template’, ‘interfaces.j2’) }}”

– name: CREATING TEMPORARY FILE TO MANUALLY CHECK THAT EDIT-CONFIG IS CORRECT II
template:
src: network_instance_interfaces.j2
dest: /tmp/oc_{{ inventory_hostname }}_ni.conf
mode: 0755
when: ansible_network_os == “sros”

The key point here is port. We have changes it to “22” instead of “830”. Also we have explicitly put datastore as “running” cause it looks like Arista doesn’t support candidate config. There is default fall back, so it isn’t mandatory to specify this. I’ve done it just for sake of clarity.

So the work is done in the same fashion it was done for previous two vendors. If we test the execution of this Ansible playbook, it looks nice :

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

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

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

TASK [arista/128_lab : IMPORTING VARS] ********************************************************************
k: [vEOS2]

TASK [arista/128_lab : CREATING TEMPORARY FILE TO MANUALLY CHECK THAT EDIT-CONFIG IS CORRECT I] ***********
ok: [vEOS2]

TASK [arista/128_lab : OPENCOFNIG // CONFIGURING INTERFACES I] ********************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: SSHError: Could not open socket to vEOS1:22
changed: [vEOS2]

TASK [arista/128_lab : CREATING TEMPORARY FILE TO MANUALLY CHECK THAT EDIT-CONFIG IS CORRECT II] **********
skipping: [vEOS2]

TASK [arista/128_lab : OPENCOFNIG // CONFIGURING INTERFACES II] *******************************************
skipping: [vEOS2]
to retry, use: –limit @/home/aaa/ansible/128_lab.retry

But again, there are no changes in the configuration of the Arista vEOS2 after the playbook is implemented.

Here is the Ansible playbooks created in this lab:

Lessons learned

There are good and bad news:

• The good news is that vendors are working on the introduction of OpenConfig in their NOSs. And the article shows that there are a lot of similar in terms of OpenConfig in Cisco, Nokia and Arista.
• The bad news that all vendors has either deviations (something from OpenConfig YANG model isn’t supported) or augments (something vendor specific is added). Both those things you might have seen in the examples provided above.

I hope further development of OpenConfig and IETF YANG models will one day lead to purely programmable in a single manner network using single YANG data model

Greetings and acknowledges

Many thanks for Alex Nichol from Arista for sharing the latest version of Arista vEOS, which supports the latest OpenConfig models implemented in Arista. Thanks for Greg Hankins from Nokia for sharing info on OpenConfig in Nokia and providing configuration guide for VSIM. And special thanks to my friend Nicola Arnoldi, who has shown wonderful ASCII graph editor to me.

Conclusion

In this article we have reviewed what OpenConfig YANG data model is and how this model can be used for configuration of the interfaces for Arista EOS, Cisco IOS XR and Nokia (Alcatel-Lucent) SR OS. In my opinion, the results are quite positive. As we stated in the beginning of the article, in the next one we’ll review the configuration of BGP for undelaying data centre using OpenConfig YANG data model as well. Take care and good bye!

Support us

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