Just before Cisco Live US, Cisco unveiled “The Network. Intuitive.” and with it is “Introducing an entirely new era of networking.” If you’re like me, you are likely intrigued, and are asking yourself.. “How do I get started?”.
A great first place to start is reading Jeff McLaughlin’s recent blog post “The New Network – It’s for Developers!” In it, Jeff talks about four features of IOS XE that provide developers new capabilities and options for working with IOS XE. They are
- Zero Touch Provisioning
- NETCONF/YANG
- On-Box Python
- Application Hosting
With these new features, one might say “the sky is the limit” or “you are only limited by your imagination”. While true, it can be a bit daunting for an experienced network engineer new to network programmability. I’ve been working in the “Software Defined Networking” space for a while now and I still find myself needing a strategy to learn the new features that are being so rapidly developed and provided today. So today I’m going to show how you can ease into new technologies using the safety and mastery of CLI. Let’s look at how I approached learning about and leveraging one of these new features, NETCONF/YANG. If you are unfamiliar with NETCONF/YANG, let me provide a quick explanation.
NETCONF (Network Configuration Protocol) is a standard transport protocol for communicating with network devices, retrieving operational data and both setting and reading configuration data. Operational data would include interface statistics, memory utilization, errors, and so on. The configuration data refers to how particular interfaces, routing protocols, and other features are enabled and provisioned. NETCONF purely defines how to communicate with the devices, but doesn’t address the what related to the data that is sent and received.
YANG (Yet Another Next Generation) is the standard data modeling language for NETCONF and is used to describe the what in this new method of network configuration. NETCONF/YANG are often referred to as “Model Driven Programmability” and YANG refers to the “models” that are “driving programmability”. The networking industry is using YANG to develop well defined data models to describe the networking concepts in a way that is reliable and consistent. For example, using the ietf-interfaces YANG model, the industry now has a standard way to describe everything about a network interface, and everyone who understands this model can communicate with confidence across hardware and software platforms as well as across vendors.
Used together, NETCONF and YANG provide both the what (YANG) and how (NETCONF) so you can programmatically interface with the network.
Training wheels or a security blanket … Let’s Start out with CLI
So, newly informed about the fact that there is a new standard for configuring our network kit, I want to dive in and test it out… My general strategy when approached with this challenge is to start at the end and work backwards. What I mean by that is rather than taking a blank configuration and try to stumble through how to use NETCONF/YANG to implement the configuration, I will configure my device the same way I normally do (CLI) and then see how I can read back that known configuration using the new tool.
Figure 1 – Configuring as usual
I’d like to develop a Python script that will configure the standard device configuration parameters I deploy to every switch and router in my network using NETCONF and YANG. In this case, that includes:
- domain-name information
- time zone
- AAA configuration
- SNMP communities
- Syslog servers
- Line config
- NTP Servers
Rather than completely try to blindly stumble around the new network APIs, it would be good to get a little bit of training to kick start me in the right direction, and it so happens that up on DevNet Learning Labs, there is a learning module on Standard Device Interfaces that will give me an introduction to using NETCONF and YANG, as well as some sample code I can use as a starting point.
It’s one of several modules in DevNet’s Network Programmability for Network Engineers Learning Track. This learning track includes 10 different labs – taking you from programming foundation elements where you’ll learn the basics of how to use REST APIs, to understanding device level interfaces (e.g., NETCONF/YANG), and how to develop with network controllers like APIC-EM.
By investing an hour into these labs I’m in good shape to get started.
The next hurdle to jump is what gear to use to do my testing and coding. Well, it just so happens that same Learning Lab that provided me the sample code and some knowledge, also introduced me to the DevNet Sandbox where I can spin up and get access to my very own IOS XE Sandbox for learning about and testing my NETCONF/YANG code.
The premise behind this exercise is that I’m going to go ahead and configure my device using the CLI to start out. So here is the configuration that I manually enter into my newly reserved IOS XE device.
Now, with my device configured, I use the sample code and knowledge from the Learning Labs to from my device and see what I get back. Here is the bit of code that will connect to the device using NETCONF and return back the full configuration as modeled by YANG.
I’ve created this script and named it “get_full_configuration.py” on my workstation. I run it with this command:
python get_full_configuration.py
When I run this script I get the following output in my terminal window.
(The output in this post has been abridged to include the relevant configuration parameters from the example. The full output includes the full configuration and can be viewed by replicating the example on your own)
Okay… now what do I do?
Alright, I’ve connected to my device and printed out a lot of information, but what next? The first step is to just read through it and become comfortable with the XML data format that is used by NETCONF. At this stage, there are really just a few key parts of the format that are important to understand.
- XML is a tag based format like HTML, so you’ll always find opening <tags> and closing <tags> surrounding elements
- If there is no data in an element, the opening and closing tags can be combined like this: <tag/>
- NETCONF leverages RPCs or Remote Procedure Calls, and this is evident because the <data> is enclosed in an <rpc-reply>
- The YANG data (the what) exists between the <data> and </data> tags
- Within a <tag> references to xmlns (XML Namespace) indicate the YANG data model that is being used
- For example: <native xmlns=”http://cisco.com/ns/yang/Cisco-IOS-XE-native”>
- Though the data model listed looks like a web url, it is not a navigable path. Find details on this YANG Data Model on GitHub
When I review the outputted data, I can find all the configuration standards I manually configured represented in the XML format. If I had tried to construct this XML representation from scratch, I expect I would have struggled quite a bit, but by reading the configuration from the IOS XE device and printing it out, I now have generated a known good NETCONF configuration for my standards. With that I can build a script that would read that data from a file and push the configuration via NETCONF to my device. Let’s look at that next.
The Configuration Script
The script to do the configuration is very similar to the first script, with the difference being that we are now using edit_config instead of get_config.
In addition, you should notice that we are referencing an external file called “standard_config.xml”. This file is the YANG payload from the previous script surrounded by tags, which are used in the NETCONF standard to indicate configuration data being sent to a device for implementation.
By George … we’ve done it!
And just like that we’ve completed the task we set out to complete. We have built a Python script that we can use to implement our standard network configuration using NETCONF and YANG, and we’ve done it with only a dozen lines of functional code (comments and line wraps don’t count :-). Whats nice in this example is that we didn’t need a full understanding of the new protocols of NETCONF and YANG. Rather we are leveraging our existing knowledge base, and some basic crawl, walk, run learning methodology that has served us well throughout our career.
If you’d like to see all the code used in this exercise, you can find it on my GitHub account
We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!
Twitter @CiscoDevNet | Facebook | LinkedIn
Visit the new Developer Video Channel
CONNECT WITH US