Everyone who has any interest in network automation inevitably comes across NETCONF and YANG. These technologies have mostly been implemented for and adopted by big telcos and service providers, while support in the enterprise/DC gear has been virtually non-existent. Things are starting to change now as NETCONF/YANG support has been introduced in the latest IOS XE software train. That’s why I think it’s high time I started another series of posts dedicated to YANG, NETCONF, RESTCONF and various open-source tools to interact with those interfaces.
To kick things off I will show how to use ncclient and pyang to configure interfaces on Cisco IOS XE device. In order to make sure everyone is on the same page and to provide some reference points for the remaining parts of the post, I would first need to cover some basic theory about NETCONF, XML and YANG.
NETCONF is a network management protocol that runs over a secure transport (SSH, TLS etc.). It defines a set of commands (RPCs) to change the state of a network device, however it does not define the structure of the exchanged information. The only requirement is for the payload to be a well-formed XML document. Effectively NETCONF provides a way for a network device to expose its API and in that sense it is very similar to REST. Here are some basic NETCONF operations that will be used later in this post:
- hello - messages exchanged when the NETCONF session is being established, used to advertise the list of supported capabilities.
- get-config - used by clients to retrieve the configuration from a network device.
- edit-config - used by clients to edit the configuration of a network device.
- close-session - used by clients to gracefully close the NETCONF session.
All of these standard NETCONF operations are implemented in ncclient Python library which is what we’re going to use to talk to CSR1k.
There are several ways to exchange structured data over the network. HTML, YAML, JSON and XML are all examples of structured data formats. XML encodes data elements in tags and nests them inside one another to create complex tree-like data structures. Thankfully we are not going to spend much time dealing with XML in this post, however there are a few basic concepts that might be useful for the overall understanding:
- Root - Every XML document has one root element containing one or more child elements.
- Path - is a way of addressing a particular element inside a tree.
- Namespaces - provide name isolation for potentially duplicate elements. As we’ll see later, the resulting XML document may be built from several YANG models and namespaces are required to make sure there are no naming conflicts between elements.
The first two concepts are similar to paths in a Linux filesystem where all of the files are laid out in a tree-like structure with root partition at its top. Namespace is somewhat similar to a unique URL identifying a particular server on the network. Using namespaces you can address multiple unique
/etc/hosts files by prepending the host address to the path.
As with other structured data formats, XML by itself does not define the structure of the document. We still need something to organise a set of XML tags, specify what is mandatory and what is optional and what are the value constraints for the elements. This is exactly what YANG is used for.
YANG was conceived as a human-readable way to model the structure of an XML document. Similar to a programming language it has some primitive data types (integers, boolean, strings), several basic data structures (containers, lists, leafs) and allows users to define their own data types. The goal is to be able to formally model any network device configuration.
Anyone who has ever used Ansible to generate text network configuration files is familiar with network modelling. Coming up with a naming conventions for variables, deciding how to split them into different files, creating data structures for variables representing different parts of configuration are all a part of network modelling. YANG is similar to that kind of modelling, only this time the models are already created for you. There are three main sources of YANG models today:
- Equipment Vendors create their own “native” models to interact with their devices.
- Standards bodies (e.g. IETF and IEEE) were supposed to be the driving force of model creation. However in reality they have managed to produce only a few models that cover basic functionality like interface configuration and routing. Half of these models are still in the “DRAFT” stage.
- OpenConfig working group was formed by major telcos and SPs to fill the gap left by IETF. OpenConfig has produced the most number of models so far ranging from LLDP and VLAN to segment routing and BGP configurations. Unfortunately these models are only supported by high-end SP gear and we can only hope that they will find their way into the lower-end part of the market.
Be sure to check of these and many other YANG models on YangModels Github repo.
My test environment consists of a single instance of Cisco CSR1k running IOS XE 16.04.01. For the sake of simplicity I’m not using any network emulator and simply run it as a stand-alone VM inside VMWare Workstation. CSR1k has the following configuration applied:
1 2 3 4 5 6 7
The last command is all what’s required to enable NETCONF/YANG support.
On the same hypervisor I have my development CentOS7 VM, which is connected to the same network as the first interface of CSR1k. My VM is able to ping and ssh into the CSR1k. We will need the following additional packages installed:
Device configuration workflow
The following workflow will be performed in both interactive Python shell (e.g. iPython) and Linux bash shell. The best way to follow along is to have two sessions opened, one with each of the shells. This will save you from having to rerun import statements every time you re-open a python shell.
1. Discovering device capabilities
The first thing you have to do with any NETCONF-capable device is discover its capabilities. We’ll use ncclient’s manager module to establish a session to CSR1k. Method
.connect() of the manager object takes device IP, port and login credentials as input and returns a reference to a NETCONF session established with the device.
1 2 3 4 5 6
When the session is established, server capabilities advertised in the hello message get saved in the
server_capabilities variable. Last command should print a long list of all capabilities and supported YANG models.
2. Obtaining YANG models
The task we have set for ourselves is to configure an interface. CSR1k supports both native (Cisco-specific) and IETF-standard ways of doing it. In this post I’ll show how to use the IETF models to do that. First we need to identify which model to use. Based on the discovered capabilities we can guess that ietf-ip could be used to configure IP addresses, so let’s get this model first. One way to get a YANG model is to search for it on the Internet, and since its an IETF model, it most likely can be found in of the RFCs.
Another way to get it is to download it from the device itself. All devices supporting RFC6022 must be able to send the requested model in response to the
get_schema call. Let’s see how we can download the ietf-ip YANG model:
At this stage the model is embedded in the XML response and we still need to extract it and save it in a file. To do that we’ll use python
lxml library to parse the received XML document, pick the first child from the root of the tree (data element) and save it into a variable. A helper function write_file simply saves the Python string contained in the
yang_text variable in a file.
1 2 3 4
Back at the Linux shell we can now start using pyang. The most basic function of pyang is to convert the YANG model into one of the many supported formats. For example, tree format can be very helpful for high-level understanding of the structure of a YANG model. It produces a tree-like representation of a YANG model and annotates element types and constraints using syntax described in this RFC.
1 2 3 4 5 6 7 8 9 10 11
From the output above we can see the ietf-ip augments or extends the interface model. It adds new configurable (rw) containers with a list of IP prefixes to be assigned to an interface. Another thing we can see is that this model cannot be used on its own, since it doesn’t specify the name of the interface it augments. This model can only be used together with
ietf-interfaces YANG model which models the basic interface properties like MTU, state and description. In fact
ietf-ip relies on a number of YANG models which are specified as imports at the beginning of the model definition.
1 2 3 4 5 6 7 8 9 10 11 12
Each import statement specifies the model and the prefix by which it will be referred later in the document. These prefixes create a clear separation between namespaces of different models.
We would need to download all of these models and use them together with the ietf-ip throughout the rest of this post. Use the procedure described above to download the ietf-interfaces, ietf-inet-types and ietf-yang-types models.
3. Instantiating YANG models
Now we can use pyangbind, an extension to pyang, to build a Python module based on the downloaded YANG models and start building interface configuration. Make sure your
$PYBINDPLUGIN variable is set like its described here.
ietf_ip_binding.py is now ready for use inside the Python shell. Note that we import
ietf_interfaces as this is the parent object for
ietf_ip. The details about how to work with generated Python binding can be found on pyangbind’s Github page.
1 2 3 4
To setup an IP address, we first need to create a model of an interface we’re planning to manipulate. We can then use
.get() on the model’s instance to see the list of all configurable parameters and their defaults.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
The simples thing we can do is modify the interface description.
New objects are added by calling
.add() on the parent object and passing unique key as an argument.
1 2 3 4
At the time of writing pyangbind only supported serialisation into JSON format which means we have to do a couple of extra steps to get the required XML. For now let’s dump the contents of our interface model instance into a file.
1 2 3 4
4. Applying configuration changes
Even though pyanbind does not support XML, it is possible to use other pyang plugins to generate XML from JSON.
interface.xml file contains the XML document ready to be sent to the device. I’ll use read_file helper function to read its contents and save it into a variable. We should still have a NETCONF session opened from one of the previous steps and we’ll use the edit-config RPC call to apply our changes to the running configuration of CSR1k.
1 2 3 4
If the change was applied successfully
reply.ok should return
True and we can close the session to the device.
Going back to the CSR1k’s CLI we should see our changes reflected in the running configuration:
1 2 3 4 5 6 7 8 9 10
Checkout this Github page for Python scripts that implement the above workflow in a more organised way.
In this post I have merely scratched the surface of YANG modelling and network device programming. In the following posts I am planning to take a closer look at the RESTCONF interface, internal structure of a YANG model, Ansible integration and other YANG-related topics until I run out of interest. So until that happens… stay tuned.