Open NX-OS

The Rise of Network Automation

Automation is dramatically changing how Datacenter networks are managed. Here we will discuss how to manage your network using YANG models.

Models

NXOS has a comprehensive number of both native and open YANG models, that allow you to manage the rich feature-set that NXOS provides. Data models provide a structured and well-defined base that facilitates programmatic interaction with NXOS devices. The list of supported models includes native, OpenConfig and IETF models. In addition, YANG provides a modeling language optimized for network devices and with a growing number of tools and utilities. OpenConfig and IETF are vendor agnostic models, that abstract the detailed configuration across OSs and platforms.

Transports

NETCONF is a protocol defined by the IETF to “install, manipulate, and delete the configuration of network devices”. NETCONF operations are realized on top of a Remote Procedure Call (RPC) layer using an XML encoding and provides a basic set of operations to edit and query configuration on a network device.

RESTCONF is a REST like protocol running over HTTP for accessing data. It is an IETF draft that describes how to map a YANG specification to a RESTful interface. REST interfaces are based on the YANG data modeling language using NETCONF datastores.

Encodings

The separation of encodings from the choice of model and protocol provides additional flexibility. Encoding in both JSON and XML are supported, providing well understood formats in which the data can be structured.

The model driven programmability features in Cisco NXOS provide a flexible infrastructure for network automation. What makes it rich and flexible? The below diagram, gives a gives an indication of the wide variety and protocols, encoding and transports with which you can interact with NXOS.

NETCONF LAYERING MODEL

Tools

There are many opensource tools with which we can automate the management on Nexus devices. Below are 3 differnet opensource tools, that that give you the power to automate your network in a programmatic manner.

  • NCCLIENT - NCCLIENT is a Python library that facilitates client-side scripting and application development around the NETCONF protocol.
  • PYANG PYANG is a YANG validator, and code generator, written in python.
  • YDK YDK is an open source tool, developed by Cisco, to facilitate network programmability using data models. YDK can generate APIs in a variety of programming languages using YANG models.

To install these packages, simply enter the following command in a terminal

Code Snippet
Copy$sudo pip install pyang ncclient ydk

The Models

Using these tools let's start with a quick look at some the capabilities provided in NXOS 7.0.3.I5(2).

The following python script will allow us to see what we can configure on a Nexus 3000/9000

Code Snippet
Copyfrom ncclient import manager
import re

nexus = manager.connect(host='n9kv-1', port=830, username='cisco', password='cisco',
    allow_agent=False,
    look_for_keys=False,
    hostkey_verify=False,
    unknown_host_cb=True)

for capability in nexus.server_capabilities:
    print capability

A snippet of the output shows that we can configure vlans using the OpenConfig model:

Code Snippet
Copyhttps://openconfig.net/yang/vlan?revision=2016-05-26&module=openconfig-vlan

We have now established that we can configure vlans using OpenConfig YANG model, on a Nexus 3000/9000, but what is the format?

As the format can be quite verbose, we are going to utilize pyang and tree to reduce the output to an easily readable format. The will show all the user configurable fields (rw), the state values(ro) as well as the other models that it augments.

Code Snippet
Copy$ pyang -f tree openconfig-vlan.yang
module: openconfig-vlan
   +--rw vlans
      +--rw vlan* [vlan-id]
         +--rw vlan-id    -> ../config/vlan-id
         +--rw config
         |  +--rw vlan-id?   oc-vlan-types:vlan-id
         |  +--rw name?      string
         |  +--rw status?    enumeration
         |  +--rw tpid?      identityref
         +--ro state
         |  +--ro vlan-id?   oc-vlan-types:vlan-id
         |  +--ro name?      string
         |  +--ro status?    enumeration
         |  +--ro tpid?      identityref
         +--rw members
            +--ro member*
               +--ro interface-ref
                  +--ro state
                     +--ro interface?      -> /oc-if:interfaces/interface/name
                     +--ro subinterface?   -> /oc-if:interfaces/interface[oc-if:name=current()/../interface]/subinterfaces/subinterface/index
augment /oc-if:interfaces/oc-if:interface/oc-if:subinterfaces/oc-if:subinterface:
   +--rw vlan
      +--rw config
      |  +--rw vlan-id?   union
      +--ro state
         +--ro vlan-id?   union
augment /oc-if:interfaces/oc-if:interface/oc-eth:ethernet:
   +--rw switched-vlan
      +--rw config
      |  +--rw interface-mode?   oc-vlan-types:vlan-mode-type
      |  +--rw native-vlan?      union
      |  +--rw access-vlan?      union
      |  +--rw trunk-vlans*      union
      +--ro state
         +--ro interface-mode?   oc-vlan-types:vlan-mode-type
         +--ro native-vlan?      union
         +--ro access-vlan?      union
         +--ro trunk-vlans*      union
augment /oc-if:interfaces/oc-if:interface/oc-lag:aggregation:
   +--rw switched-vlan
      +--rw config
      |  +--rw interface-mode?   oc-vlan-types:vlan-mode-type
      |  +--rw native-vlan?      union
      |  +--rw access-vlan?      union
      |  +--rw trunk-vlans*      union
      +--ro state
         +--ro interface-mode?   oc-vlan-types:vlan-mode-type
         +--ro native-vlan?      union
         +--ro access-vlan?      union
         +--ro trunk-vlans*      union
augment /oc-if:interfaces/oc-if:interface:
   +--rw routed-vlan
      +--rw config
      |  +--rw vlan?   union
      +--ro state
         +--ro vlan?   union

Using this we can now easily navigate the tree to help us build the required object. We want to be able to create these objects in a programmatic manner, and to be removed from the manually generating these objects. To achieve this we will use YDK.

The below script is all that is required to generate the object required to create a vlan. This can then be provisioned on the network in an automated manner. Here we are printing the object, just to show how using tools such as YDK have simplified the creation of such an object.

Code Snippet
Copyfrom ydk.services import CRUDService, NetconfService, Datastore, CodecService
from ydk.providers import NetconfServiceProvider, CodecServiceProvider
from ydk.models.openconfig.openconfig_vlan import Vlans
from ydk.models.ietf import iana_if_type

vlan = Vlans.Vlan()
vlan.config.name = "DB"
vlan.config.vlan_id = 20
vlan.vlan_id = vlan.config.vlan_id
vlan.config.status = 'ACTIVE'

provider = CodecServiceProvider(type="xml")
codec = CodecService()
print codec.encode(provider, vlan)

Output:

Code Snippet
Copy<vlan xmlns="https://openconfig.net/yang/vlan">
  <vlan-id>20</vlan-id>
  <config>
    <name>DB</name>
    <status>ACTIVE</status>
    <vlan-id>20</vlan-id>
  </config>
</vlan>

Conclusion

Using tools such as NCCLIENT or YDK this object can then be used to create the vlan on the network. The power of automation is that this is repeatable and scalable and can be be achieved for all models that are supported on NXOS. In this example, YDK generates the objects and ensures that all dependenices are met while removing us from the detailed syntax of the YANG model. Interacting with the network in this manner, enables you to manage your network in a more scalable and efficient manner.

Next