This blog is authored by Jeremy Cohoe and Kareem Iskander

As Cisco platforms (IOS XE, IOS XR, NX-OS) continue to support IETF, OpenConfig, and Cisco Native YANG models, we needed to develop a tool to help make the lives of network automation engineers easier!

Cue in Cisco Yang Suite

Cisco YANG Suite provides a set of tools and plugins to learn, test, and adopt YANG programmable interfaces such as NETCONF, RESTCONF, gNMI and more.

Imagine trying to leverage a new API endpoint to build your application without using some sort of testing tool to understand the endpoint and what it returns. That’s not ideal or efficient.

This is what YANG Suite enables you to do when it comes to network programmability.

YANG Suite is built on a flexible architecture that is modular and plugin-based. The base plugins include the YANG file manager, the devices manager, a plugin for comparing YANG datasets and running diff’s, support for NECONF, and for receiving gRPC Model Driven Telemetry. YANG Suite is available directly from the online Python Package Index which means that each of these plugins as well as the YANG Suite core itself can easily be upgraded once installed and running – updates are built in to the tool and are accessible by navigating to “Manage Plugins > Update”

YANG Suite’s NETCONF plugin is one of the most used features of YANG Suite. The NETCONF plugins enables interacting with the network device over the NETCONF-YANG interface, building XML payloads based off of the YANG model, preforming the RFC standard get, get-config, edit-config, and action RPC operations, as well as supports working with the candidate datastore.

Get Started with Cisco Yang Suite

Alright let’s get you all set up. Git is required to clone the Github repository, and both the Docker engine and Docker-compose are also needed. What we are about to do is clone the docker file from GitHub, navigate to the Docker image folder and bring up the container with YANG Suite running. Docker is used to create 3 containers: one for YANG Suite, one for the Nginx webservice, and one to store the YANG and runtime files in.

git clone https://github.com/CiscoDevNet/yangsuite

cd yangsuite/docker/ ; ./gen_test_certs.sh

docker-compose up

Yang Suite is now running on your localhost here –

Now that YANG Suite has been installed and is accessible on your system, the day 0 workflow is as follows:

  1. Add a device or devices
  2. Download the YANG modules from the device or import from Git
  3. Explore YANG, compare, build API calls, send, and test the various APIs

The YANG Suite Learning Lab has a detailed walkthrough for completing the Day 0 workflow within YANG Suite. In the example below the DevNet Always-On IOS XE Sandbox CSR1000 is added to the device profiles and used to download YANG models.

YANG Suite

Once the device is added then the YANG modules can be downloaded and are available for interacting with from the specified “YANG Set” that is created. Multiple YANG Sets and Repositories are supported, so when you have a combination of YANG models from IOS XE, IOS XR, and NX-OS then it becomes easier to sort, group, and compare, and filter the YANG as needed. YANG Suite is ready once YANG files are loaded, so the next step might be to start sending some payloads to network devices.

YANG Suite

The NETCONF plugin is used to build the XML payloads and send them to the device – the returned response is seen instantly. In this example the Cisco-IOS-XE-interfaces-oper.YANG module is used to collect the interface statistics for the GigabitEthernet1 interface on the Always On CSR1000:

Yang Suite

Once the “Run RPC” button is selected then a new window pops up with the results. Examining the data shows some basic interface statistics and counters have been returned, this is a very common use case to understand the traffic on the ethernet interface of this device. The packets and bytes in and out of the interface are reported, as well as some other counters.

<?xml version="1.0" ?>
<rpc-reply message-id="" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <interfaces xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-interfaces-oper">

NETCONF Plugin with Telemetry

Performing a NETCONF GET operation to understand feature state is one common use case with the YANG interfaces. But moving beyond one-time or static collection to a more dynamic and model driven telemetry collection is often desirable. The NETCONF RFC8641 has draft support for the yang-push mechanism for streaming telemetry, and YANG Suite helps to both enable tha telemetry as well as receive and collect it. Let’s build the XML payload then send it to the device, then review the telemetry data stream as it comes into the new window within YANG Suite!

Building the NETCONF payload to enable telemetry is possible by using the IETF-event-notifications.YANG and requires 4 parameters to be entered to enable the telemetry configuration:

  1. Define the stream as yang-push
  2. Set the encoding to key-value
  3. Set the Xpath filter – this is the data to collect, in this case it is CPU utilization
  4. Define the update interval in centiseconds, 1000 means every 10 seconds data will be pushed

We can build this XML payload within YANG Suite:

YANG Suite xml-build

Once the “Run RPC” button is selected a new window appears and the streaming telemetry is displayed, being updated every 10 seconds.

YANG Suite runrpc

The CPU utilization is at 0% at both collection intervals. Putting this data into a Time Series Database such as InfluxDB or into another data visualization tool like Splunk or Elasticsearch is when the real power of network telemetry data can be observed. In the example below the CPU data is displayed within Grafana, part of the Telegraf and InfluxDB stack described in more details in this blog.

YANG Suite

As you can see, YANG Suite has a lot of features and potential. From working with a variety of network devices, to managing sets of YANG files, exploring and comparing YANG files, interacting with NETCONF, collecting model driven telemetry, as well as a variety of other use cases. This is tooling to help network engineers and network automation spend less time on network operations so that more innovation and business value can be delivered.

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


Jeremy Cohoe

Technical Marketing Engineer

Enterprise Networking