Welcome back again to our series of blogs on system automation and programmability with Cisco Open NX-OS. By today you have become acquainted with Vagrant and how to run your personal virtual instance of Cisco NX-OS, how exactly to enable NX-API and utilize the NX-API CLI and NX-API REST. You’ve seen the NX-API Sandbox and how exactly to configure and monitor Cisco Nexus switches utilizing the code generated by the sandbox. You’ve got a considerable group of tools in order to begin automating Cisco Nexus systems at this stage. But what if you want to take system automation to another degree and develop your personal NX-OS functions? Is that possible even?

Take network automation to another level

I’m pleased to say that Indeed, the choice is had by one to develop your personal NX-OS features, custom CLIs, syslog text messages, error and event managers, and whatever custom made applications it is possible to think of. To carry out this, Cisco provides NX-SDK, a C++ abstraction and plugin-library level that streamlines usage of NX-OS backend infrastructure procedures. You obtain the same usage of the core the different parts of the Cisco Nexus switches that the Cisco NX-OS developers do if they develop new functions and new releases.

Developing your personal CLI instructions in NX-OS

In this website post we will discover NX-SDK and how to begin with developing your personal CLI commands in NX-OS. The task is to create two brand-new CLI instructions: a show control which will display the change port bandwidth utilization in proportion and a configuration order that will fixed a port bandwidth utilization threshold that when crossed, a syslog information will be generated.

When you could follow the instructions about Github at to create your personal development environment, I thought we would utilize the Docker container. It has all of the prerequisites and elements included as my advancement environment. Once you docker pull the picture, you can begin the container and obtain usage of the bash shell in the container with the next command:

docker work -it dockercisco/nxsdk:v1.7.5 /bin/bash

This should offer you usage of the bash shell in the Docker container:

Luckily enough an example NX-OS application that accomplishes the requirements we set at first are available within the NX-SDK/examples/python folder and it’s called pbwMonitor.

Permit’s have got a closer understand this Python application

You can either utilize the vi editor within the Docker container or even it is possible to simply git clone the repo on your own local machine and start the /examples/python/pbwMonitor file in your preferred text editor.

This Python application has all of the components had a need to create the show and config commands for the switch port bandwidth utilization. First of all the import nx_sdk_py provides the nx_sdk_py library within the application form. This library will undoubtedly be used to produce a hook back to the NX-OS backend procedures and to develop a new course that extends the NxCmdHandler course. Extra libraries are included to greatly help with building the application form also.

The print_port_bw() function needs as input the outcomes of the present interface command, computes the port bandwidth utilization, generates a syslog information if the bandwidth utilization is certainly less or add up to the arranged threshold and prints to the CLI the bandwidth utilization. Online 66 of the Python application be sure you replace eth_bw = int(worth_ascii) with eth_bw = int(worth_ascii.split()[0]). That is needed in afterwards versions of NX-Operating system, which includes version 9.3.3 that people have jogging in Vagrant, as the bandwidth output contains furthermore the Kbit phrase with the integer worth of the bandwidth collectively. The split function put on the worth_ascii string, splits the string right into a list of specific strings and eth_bw includes only the initial value (index 0) that is the bandwidth value.

Without this modification, when working the application form on the switch, you shall obtain the following mistake message on NX-OS 9.3.3:

Nexus9000v(config)# show pbwMonitor port bw utilization
Port BW Threshold limit: 50

User interface Bw (Rx/Tx Sec Price) Tx_BW portion RX_BW percentage
————— ——————– —————— ——————
Inside method ‘postCliCb’: ValueError: invalid literal for int(): 1000000 Kbit: range 66

The timerThread() function runs every 60 secs and uses the print_port_bw() function to calculate the bandwidth utilization in all ports and generate the syslog information in the event the threshold is normally crossed.

The pyCmdHandler(nx_sdk_py.NxCmdHandler) course extends the NxCmdHandler course and defines the application form callback within the postCliCb() perform. The callback handler will get a pointer to the NxCmdHandler and NxCliCmd items over that your behavior of both new commands (show_interface_bw_util_cmd and slot_bw_threshold_cmd) is defined.

The sdkThread() function performs all SDK associated initializations in a single thread. Gaining usage of the NXOS infra is performed by instantiating a fresh NxSdk object:

sdk = nx_sdk_py.NxSdk.getSdkInst(len(sys.argv), sys.argv)

The CLI possibilities for both new commands are defined here. The show_interface_bw_util_cmd control from the callback functionality becomes show slot bw utilization [ | hit-threshold] for the customers of the CLI and the config setting command slot_bw_threshold_cmd from the callback perform becomes interface bw threshold

within the CLI of NX-OS. You can even see here the way the command choices and their help details are being defined therefore that once you do ? in the CLI the precise information as defined will displayed to an individual here.

Final initializations are completed at the ultimate end of the Python application such as for example defining global variables, initializing a fresh timer and sdkThread.

The NX-SDK posseses an RPM generator that takes as input source code files and outputs RPM packages which can be installed on the Nexus switches. To be able to generate an RPM bundle from the pbwMonitor program using rpm_gen.py, the next command must be executed in the NX-SDK Docker container:

python NX-SDK/scripts/rpm_gen.py pbwMonitor -s NX-SDK/good examples/python/ -u

The output should appearance like the following:

####################################################################################################
Generating rpm package...
Executing(%prep): /bin/sh -e /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/var/tmp/rpm-tmp.9625
+ umask 022
+ cd /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../src/rpm/BUILD
+ exit 0
Executing(%create): /bin/sh -e /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/var/tmp/rpm-tmp.9625
+ umask 022
+ cd /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../src/rpm/BUILD
+ exit 0
Executing(%install): /bin/sh -e /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/var/tmp/rpm-tmp.21128
+ umask 022
+ cd /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../src/rpm/BUILD
+ /bin/rm -rf /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/pbwMonitor-root
+ /bin/mkdir -p /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/pbwMonitor-root
+ rm -rf /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/pbwMonitor-root//isan/bin/nxsdk
+ mkdir -p /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/pbwMonitor-root//isan/bin/nxsdk
+ cp -R /NX-SDK/illustrations/python/pbwMonitor /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/pbwMonitor-root//isan/bin/nxsdk
+ exit 0
Processing files: pbwMonitor-1.0-1.7.5.x86_64
Checking for unpackaged document(s): /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/check-documents /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/pbwMonitor-root
Wrote: /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/src/rpm/SRPMS/pbwMonitor-1.0-1.7.5.src.rpm
Wrote: /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/src/rpm/RPMS/x86_64/pbwMonitor-1.0-1.7.5.x86_64.rpm
Executing(%thoroughly clean): /bin/sh -e /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/var/tmp/rpm-tmp.21128
+ umask 022
+ cd /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../src/rpm/BUILD
+ /bin/rm -rf /enxos-sdk/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/../../../var/tmp/pbwMonitor-root
RPM bundle has been built
####################################################################################################

SPEC document: /NX-SDK/rpm/Specifications/pbwMonitor.spec
RPM document : /NX-SDK/rpm/RPMS/pbwMonitor-1.0-1.7.5.x86_64.rpm

The RPM file that has been generated are available in the /NX-SDK/rpm/RPMS folder and is named pbwMonitor-1.0-1.7.5.x86_64.rpm. As we’ve done within this group of blog posts before, we shall utilize the NX-Operating system Vagrant instance we’ve setup previously. First, we duplicate the RPM bundle on the neighborhood machine and from the local device to the Vagrant NX-OS instance.

We shall use docker cp to copy data files between your Docker container and the neighborhood machine:

docker cp 6aff2f444633:/NX-SDK/rpm/RPMS/pbwMonitor-1.0-1.7.5.x86_64.rpm .

where 6aff2f444633 would be to container ID and available for you it will have another worth (use docker ps to get the ID of one’s Docker container).

Next let’s make use of vagrant scp to duplicate the RPM from the neighborhood device to the NX-Operating system vagrant instance. Be sure you set up the vagrant-scp plugin in the event that you haven’t currently done so:

vagrant plugin install vagrant-scp

In the CLI of the Vagrant NX-OS package, make sure you allow the scp-server and the nxsdk functions in configuration mode. The scp-server function will enable the SCP server on NX-Operating system and the nxsdk function will enable NXSDK and offer the commands to set up the RPM application:

feature scp-server
function nxsdk

Using vagrant scp, duplicate the RPM file through the local machine in order to the Vagrant NX-OS example:

vagrant scp pbwMonitor-1.0-1.7.5.x86_64.rpm febea94:/

where febea94 may be the vagrant box id for the nxos9.3.3.container (you will find the vagrant package id by issuing the vagrant global-position order). If the RPM document copy from the neighborhood device to the vagrant container went you should notice an output like the following one:

Caution: Permanently added ‘[127.0.0.1]:2222’ (RSA) to the set of known hosts.
User Accessibility Verification
pbwMonitor-1.0-1.7.5.x86_64.rpm 100% 6737 1.4MB/s 00:00

Make certain the RPM is definitely on the bootflash associated with the vagrant box simply by issuing dir bootflash: from the CLI associated with the Nexus 9000v example:

That the RPM is within the bootflash of the change now, it is possible to install and activate the application form. The next config mode instructions will make this happen:

install include bootflash:pbwMonitor-1.0-1.7.5.x86_64.rpm
install activate pbwMonitor-1.0-1.7.5.x86_64
nxsdk service-name pbwMonitor

Now that the application form has been installed upon the switch, you can operate the newest CLI commands:

show pbwMonitor slot bw utilization
pbwMonitor interface bw threshold <1-100>

As you’ve seen therefore with Vagrant for Nexus 9000v and Docker for NX-SDK far, you can very create a developer environment on your own personal laptop easily. I want to know in the remarks when you have any queries and if you’re prosperous in running your initial apps on Cisco Nexus switches.

In the next post of this series we will go over CML, and ways to expand your network simulations in one virtual change to a complete blown network.

Please go to the DevNet NX-OS Dev Center for learning tracks and developer resources linked to NX-OS. And, should you have comments or queries, please depart me a comment in the area below. I would welcome listening to from you.

The post Network Programmability and Automation with Cisco Open NX-OS –} Part 4 appeared 1st on Cisco Blogs.