In the last post, we discussed what YANG Suite is and how its major components can be configured to a point where it can be used to interact with network devices for automation purposes over protocols like NETCONF, RESTCONF etc.

In today’s part 2 of the series, we will be exploring YANG modules in detail and executing RPC operations against a CSR 1000V router. The table of contents is given below. You can click on the links to jump to the relevant section.

1. Explore
2. Build RPCs
3. Run RPCs

Explore

By this time, I assume all of us have seen what a YANG model looks like in its raw form. We have also analyzed it in a tree like structure using Pyang. But YANG Suite goes much further than that. Let’s start the first phase where we load and analyze YANG modules in the YANG Suite.

• In order to analyze a YANG module, we first need to load it into the “Explore” module. You can do that by clicking on Explore –> YANG option on the left side menu.
• Select the YANG Data set we created in Part 1 of this series and search for the module that you are interested in.

• You can start typing the keyword and select the required option from the dropdown. In this case, I am interested in capturing operational statistics of Voice traffic. Once the module is selected then click on “Load Module”.

• Once you’ve loaded the selected module, you’ll be able to see its different nodes/elements like containers/lists/leafs in a tree like structure.

• If you want to get further details on these items within the tree structure, then simply click on any of them.
• For example, I selected “active-voip-call-summary” container and the following is what I got. I’ve marked some of the critical pieces of information like its Xpath value (we’ll discuss it in some later tutorial), access (read-only) and type of operations (get) permitted on this container etc.

• Here is another example concerning interface configuration on an IOS-XE device. I am interested in a particular “Leaf” called “oper-status” that belongs to a “List” called “interface”. This leaf only allows “get” operations and has “read-only” access based on the information given on the right side.

• I’d suggest you to do this exercise on other YANG modules as well based on your need. This will give you more clarity on what these YANG modules comprise of and how to utilize them in production use cases.

Build RPCs

A Remote Procedure Call or RPC as it’s popularly called is a simply request-response mechanism. It allows a computer/program to execute operations on a remote system. As we already know, NETCONF works on a client/server architecture model. Client is usually the application which is initiating the request and server is the network device. When we are executing RPCs using NETCONF protocol on a remote network device, we are basically sending instructions encoded in an XML format. Let’s look at this with an example.

• Go to Protocols –> NETCONF. Here, you’ll need to select the YANG Data set and the Device which we had added during part 1 of this exercise. You’ll also need to select the YANG module you want to work with.

• For this particular exercise, we will be working with Cisco-IOS-XE-interfaces-oper YANG model. This model captures operational state of all interfaces on a network device. I wanted to use the Voice YANG model but my lab CSR router is not running voice services. So, we wouldn’t have been able to capture any data.
• As is seen in the below given screenshot, we have successfully loaded the Cisco-IOS-XE-interfaces-oper YANG model. Now, let’s say we want to capture 3 pieces of information from this CSR router.
  • Interface Name
  • Interface Admin State
  • Interface IP Address

• Once I select above mentioned leafs and click on “Build RPC” button, I get the following. On the right side, we see the instructions which are encoded in an XML format.

• These instructions are sent to the remote device (CSR Router) as an RPC call. The beginning and closing tags make it abundantly clear.

<rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <get>
    <filter>
      <interfaces xmlns="http://cisco.com/ns/yang/Cisco-IOS-XE-interfaces-oper">
        <interface>
          <name/>
          <admin-status/>
          <ipv4/>
        </interface>
      </interfaces>
    </filter>
  </get>
</rpc>

Run RPCs

• At this point, we have successfully built an RPC. Now is the time to actually run it on the network device and capture its outcome. You can run the RPC by clicking on the “Run RPC” button.
• This will open a new window where this request-response mechanism will be pretty evident.
• The following screenshot shows the RPC “Request” which was sent by YANG Suite to the CSR Router. This is basically the RPC we built in the previous step.

• The following screenshot contains the RPC Reply or Response sent by the CSR Router. The XML output is pretty self explanatory. Our RPC request had asked for the interface’s name, admin state and IP address. The following RPC reply provides that information for all three GigabitEthernet interfaces configured on the device.

---

This was the concluding part of this 2 part series on YANG Suite and its usability vis-a-vis NETCONF. I can’t overstate the important of tools like YANG Suite and Pyang if you’re interested in understanding and exploiting the full potential of NETCONF/YANG towards network automation/programmability. I’ve only scratched the surface in this series. There is so much more that can be done by applying these principles. I’d highly suggest readers to further explore this world on their own & develop solutions based on their specific needs and use cases.

I hope this series was helpful to those who are trying to delve deeper into the world of network programmability. Please feel free to provide your feedback/suggestions, if any.

Let’s connect on LinkedIn