Originally published at: https://indeni.com/cisco-nexus-vpc-technology-ind-scripting-nx-os-python-part-3/
This is the third and final article from the Cisco Nexus virtual Port Channel (vPC) virtualization technology and Indeni series. In the previous articles we covered the main components, features and best practices implemented for the NX-OS vPC Data Center technology. Indeni discovered and analyzed the Nexus switches N9k and N5k deployed in a vPC setup at a lab environment. The outcome of the Indeni analysis triggers the vPC alerts in case of an issue. Each alert provides detailed info for the problem or for the misalignment from the best practices, alert severity level and detailed remediation steps. Finally, a dynamic report for the vPC technology and activated features is provided via the Indeni live config.
This article is going to describe the main guidelines of how the vPC script operates to analyze and trigger alerts for the NX-OS vPC technology. In particular, the metrics, live-config and the alert logic used for the vPC technology are discussed. Then, the powerful scripting capabilities embedded to the NX-OS are discussed. Finally, the powerful NX-OS embedded python environment is described and tested at the lab environment.
Are you a Network Administrator, System Engineer, Software Engineer, Indeni Knowlegde Expert (IKEs), Indeni Software Developers or Tech Geek? If yes, then read on! This article is for you!
How the script works…
This section starts with one of my favorite mottos mentioned by Benjamin Franklin :‘Tell me and I forget, teach me and I may remember, involve me and I learn.’
Let’s have a brief intro about this great historical personality. Benjamin Franklin (January 17, 1706 to April 17, 1790) was a Founding Father and a polymath, inventor, scientist, printer, politician, freemason and diplomat. His scientific pursuits included investigations into electricity, mathematics and mapmaking.
It doesn’t need to be an exceptional personality, polymath and smart like Benjamin Franklin in order to create your own Indeni scripts for the analysis of the network devices, live monitoring or to create various automated tasks. 
Everyone with a passion in Networking, Programming or a tech geek can contribute and be an active member for the development or improvement of Indeni scripts. So, as Benjamin Franklin stated only if you get involved and write your own Indeni scripts you can learn, gain more skills and boost your career!
The Cisco Nexus lab environment used in the previous articles is going to be used here. The next Cisco Nexus switches, NX-OS versions and Indeni Software Release have been used for testing:
| Hostname | Model | NX-OS Version/Release |
|---|---|---|
| N5k-UP | N5K-C5548U P-SUP | 7.0(2)N1(1) |
| N5k-down | N5K-C5548UP-SUP | 7.0(7)N1(1) |
| N9k-A | Nexus9000 9000v Chassis | version 7.0(3)I7(3) |
| N9k-B | Nexus9000 9000v Chassis | version 7.0(3)I7(3) |
| Indeni | Indeni | Installed Indeni packages: indeni-collector 6.1.4.65 indeni-ds 6.1.4.65 indeni-server 6.1.4.65 indeni-triton 6.1.4.65 indeni-vigile 6.1.4.65 indeni-walt 6.1.4.65 |
As the first step, the Indeni collector needs to interrogate the device, to determine the type of Cisco Nexus network device. The outcome of the interrogation phase is a set of tags essential to categorize the device. These tags can include “device-id” or “software-version” which are a unique identifier for a device. The tags provide additional information about the device. The process of getting the tags occurs only during the phase of interrogation. The Indeni collector will clear all of the information already known about the device and will restart interrogation in case any of these tags has been changed e.g. after a NX-OS software upgrade.
The next screenshot is from the Indeni platform installed at the lab and illustrates the tags after the interrogation of the Nexus switches. It can see a set of tags like the Device Vendor, IP address, Software version and model. The tags of the N5k are highlighted in the red box.
As soon as the interrogation phase is completed successfully the collector starts to run the “monitoring” commands periodically, collecting data from the device and parsing it into the metrics.
The nexus-vpc ind script is set to run periodically, according to the time set interval which is set equal to 5 minutes.
[sourcecode language=“plain” highlight=“5,7,8,9”]
#! META
name: nexus-vpc
description: Nexus vPC information
type: monitoring
monitoring_interval: 5 minutes ← time interval of execution
requires:
vendor: “cisco” ← tags
os.name: “nxos”
vpc: “true”
[/sourcecode]
The metrics generated will be sent off to the Indeni server and stored to the Indeni Database. The collector attaches the device-id and collection timestamp for each of the collected vPC metrics. The vPC script parses the output of the NX-OS command “show vpc” to get the relevant metrics. A sample of this command output used for parsing by the ind script is provided below. It should be mentioned that the NX-OS can provide an output in xml format by using the “| xml” at the end of each command.
[sourcecode language=“plain”]
N5k-DOWN# show vpc | xml
<?xml version=“1.0” encoding=“ISO-8859-1”?>
<nf:rpc-reply xmlns:nf=“urn:ietf:params:xml:ns:netconf:base:1.0” xmlns=“http://www.cisco.com/nxos:1.0:mcecm”>
<nf:data>
<show>
<vpc>
<__XML__OPT_Cmd_show_vpc_brief_vpc-number>
<XML__OPT_Cmd_show_vpc_brief___readonly>
<readonly>
<vpc-domain-id>1</vpc-domain-id>
<vpc-peer-status>peer-ok</vpc-peer-status>
<vpc-peer-status-reason>SUCCESS</vpc-peer-status-reason>
<vpc-peer-keepalive-status>peer-alive</vpc-peer-keepalive-status>
<vpc-peer-consistency>inconsistent</vpc-peer-consistency>
<vpc-per-vlan-peer-consistency>consistent</vpc-per-vlan-peer-consistency>
<vpc-peer-consistency-status>INVALID</vpc-peer-consistency-status>
<vpc-type-2-consistency>consistent</vpc-type-2-consistency>
<vpc-type-2-consistency-status>SUCCESS</vpc-type-2-consistency-status>
<vpc-role>primary-secondary</vpc-role>
<num-of-vpcs>1</num-of-vpcs>
<peer-gateway>disabled</peer-gateway>
<dual-active-excluded-vlans>-</dual-active-excluded-vlans>
<vpc-graceful-consistency-check-status>enabled</vpc-graceful-consistency-check-status>
<vpc-auto-recovery-status>Enabled (timeout = 240 seconds)</vpc-auto-recovery-status>
<vpc-peer-link-hdr>Start of VPC peer-link table</vpc-peer-link-hdr>
<TABLE_peerlink>
<ROW_peerlink>
<peer-link-id>1</peer-link-id>
<peerlink-ifindex>Po23</peerlink-ifindex>
<peer-link-port-state>enabled</peer-link-port-state>
<peer-up-vlan-bitset>10,100-101</peer-up-vlan-bitset>
</ROW_peerlink>
</TABLE_peerlink>
<vpc-end>End of table</vpc-end>
<vpc-hdr>Start of vPC table</vpc-hdr>
<vpc-not-es>vPC complex</vpc-not-es>
<TABLE_vpc>
<ROW_vpc>
<vpc-id>10</vpc-id>
<vpc-ifindex>Po10</vpc-ifindex>
<vpc-port-state>disabled</vpc-port-state>
<vpc-thru-peerlink>enabled</vpc-thru-peerlink>
<vpc-consistency>inconsistent</vpc-consistency>
<vpc-consistency-status>SYSERR_MCECM_GLOBAL_COMPAT_CHK_FAILED</vpc-consistency-status>
<up-vlan-bitset>-</up-vlan-bitset>
<es-attr>unknown enum:&lt;540689988&gt;</es-attr>
</ROW_vpc>
</TABLE_vpc>
<vpc-end>End of table</vpc-end>
</readonly>
</XML__OPT_Cmd_show_vpc_brief___readonly>
</__XML__OPT_Cmd_show_vpc_brief_vpc-number>
</vpc>
</show>
</nf:data>
</nf:rpc-reply>
]]>]]>
[/sourcecode]
Based on the NX-OS command output defining the metrics and the alert logic that are used for the vPC script. The next table summarizes these values for vPC and in particular the “XML tag”, “metric name” definition, “metric value” and “value logic” in order for this value to be used to trigger an alert through script rules. Rules are a mechanism through which Indeni alerts on certain issues. A rule expresses the logic of analysis of one or more metrics.
| XML TAG defined to the NX-OS command output | Metric Name | Metric Value | Metric Value |
|---|---|---|---|
| <vpc-peer-status>peer-ok</vpc-peer-status> | nexus-vpc-peer-status | 1|0 | 0 if (!peer-ok) |
| <vpc-peer-keepalive-status>peer-alive</vpc-peer-keepalive-status> ?? | nexus-vpc-keepalive | 1|0 | 0 if (!peer-alive) |
| <vpc-peer-consistency>consistent</vpc-peer-consistency> | nexus-vpc-peer-consistency | 1|0 | 0 if (!consistent) |
| <vpc-per-vlan-peer-consistency>consistent</vpc-per-vlan-peer-consistency> | nexus-vpc-per-vlan-peer-consistency | 1|0 | 0 if (!consistent) |
| <vpc-peer-consistency-status>SUCCESS</vpc-peer-consistency-status> | nexus-vpc-peer-consistency-description | SUCCESS | copy text |
| <vpc-type-2-consistency>consistent</vpc-type-2-consistency> | nexus-vpc-type-2-consistency | 1|0 | 0 if (!consistent) |
| <vpc-type-2-consistency-status>SUCCESS</vpc-type-2-consistency-status> | nexus-vpc-type-2-consistency-description | SYSERR_SVI_COMPAT_CHECK_FAILURE | copy text |
| <num-of-vpcs>1</num-of-vpcs> | nexus-vpc-num | number | copy text |
| <peer-gateway>enabled</peer-gateway> | nexus-vpc-peer-gateway | 1|0 | 0 if (Disabled or '0') |
| <vpc-graceful-consistency-check-status>enabled</vpc-graceful-consistency-c | nexus-vpc-consistency-check | 1|0 | 1 if (enabled or 1) |
Embedded NX-OS Scripting capabilities
Nexus switches offer powerful scripting capabilities since integrating Python into NX-OS can simplify network operations and automation through the ability to run Python scripts directly on the switch. The python scripts can be used to execute configuration commands, show commands, parse CLI output, call other scripts etc.The next table summarizes the NX-OS releases where the python version is supported:
| Nexus series switches | NX-OS release | Python Release |
|---|---|---|
| Nexus 5000 series | 5.2(1)N1(1) and later | Python v2.7.2 |
| Nexus 6000 series | 6.0(2)N1(1) and later | Python v2.7.2 |
| Nexus 7000 series | 6.0(2)N1(1) and later | Python v2.7.2 |
| Nexus 9000 series | 6.0(2)N1(1) and later | Python v2.7.2 |
[sourcecode language=“plain”]
N5k-DOWN# python
Copyright (c) 2001-2012 Python Software Foundation; All Rights Reserved
N5k-DOWN# >>>
[/sourcecode]
The python commands quit(), exit (), Ctrl-C or Ctrl-D (i.e. EOF) can be used to exit the python environment and switch back to well-known NX-OS privileged mode.
The embedded python in NX-OS supports the following modes:
- Interactive
- Non-interactive
[sourcecode language=“plain”]
N5k-DOWN# >>> print “I love Automation with Indeni”
I love Automation with Indeni
N5k-DOWN# >>>
[/sourcecode]
In case of non-interactive (script) mode in NX-OS it is possible to run the Python script filename as an argument to the Python CLI command.
As an example a python script named indeni.py has been created. This script was created using a standard text editor, e.g. VI editor, and has been uploaded to a TFTP server.
[sourcecode language=“plain”]
N5k-DOWN# copy tftp: bootflash:
Enter source filename: helloIndeni.py
Enter vrf (If no input, current vrf ‘default’ is considered): management
Enter hostname for the tftp server: 10.10.18.1
Trying to connect to tftp server…
Connection to Server Established.
TFTP get operation was successful
Copy complete, now saving to disk (please wait)…
[/sourcecode]
The script has been downloaded to the Nexus switch and stored in the bootflash:scripts location which is where pythons scripts must be saved and executed. The location of our Python script is shown below:
[sourcecode language=“plain”]
N5k-DOWN# dir bootflash:scripts | i hello
108 May 13 20:02:57 2017 helloIndeni.py
[/sourcecode]
The content of the basic script is provided below.
[sourcecode language=“plain”]
N5k-DOWN# show file bootflash:scripts/helloIndeni.py
#!/usr/bin/env python
import sys
argvList = sys.argv[1:]
for argv in argvList:
print 'Hello ’ + argv
[/sourcecode]
The python script is executed successfully by running the next command. It should be noted that starting from the NX-OS 7.0 version, python scripts are executed with the ‘python’ instead of the ‘source’ command
[sourcecode language=“plain”]
N5k-Down# source helloIndeni.py indeni
Hello indeni
[/sourcecode]
Now the most interesting part is that you can take advantage of the powerful embedded python capabilities supported by NX-OS and create your own NX-OS commands. The next example illustrates that a new command named ”hello” is created to call the helloindeni.py python script.
[sourcecode language=“plain”]
N5k-Down(config)# cli alias name hello source helloindeni.py
N5k-Down# hello indeni
Hello indeni
[/sourcecode]
Finally, it is possible to author a script with a batch of NX-OS commands in a file and execute them from the CLI. It is possible to combine the scripting capabilities also by taking advantage of the NX-OS EEM scripting language. The EEM script feature is supported since NX-OS Version 6.0(2)N2(1). For instance, an EEM script can check for a value or log to trigger an event or execute a script.
The content of the script NX-OS can be viewed with the command displayed below. This provides the output of the show interface command. It has not been configured descriptions at the interfaces eth1/6-8.
[sourcecode language=“plain”]
N5k-Down# sh file bootflash:///script-description.txt
configure
interface Ethernet1/16
description *** TEST 1 ***
interface Ethernet1/17
description *** TEST 2 ***
interface Ethernet1/18
description *** TEST 3 ***
end
[/sourcecode]
The current output of these interfaces is provided of the show interface command. As is illustrated, it has not been configured descriptions at the interfaces eth1/6-8.
[sourcecode language=“plain”]
N5k-Down # sh run interface
!Command: show running-config interface
!Time: Mon May 15 00:00:41 2017
version 7.0(2)N1(1)
<…>
interface Ethernet1/16
interface Ethernet1/17
interface Ethernet1/18
[/sourcecode]
Finally, the script is executed as is illustrated to the next command:
[sourcecode language=“plain”]
N5k-DOWN# run-script bootflash:///script-description2.txt
configure interface Ethernet1/16
description *** TEST 1 *** interface Ethernet1/17
description *** TEST 2 *** interface Ethernet1/18
description *** TEST 3 *** end
[/sourcecode]
Finally, the description is successfully configured to the interfaces as is shown to the output below:
[sourcecode language=“plain”]
N5k-DOWN# sh run interface
!Command: show running-config interface
!Time: Mon May 15 00:04:04 2017
version 7.0(2)N1(1)
<…>
interface Ethernet1/16
description *** TEST 1 ***
interface Ethernet1/17
description *** TEST 2 ***
interface Ethernet1/18
description *** TEST 3 ***
[/sourcecode]
Summary
This article is the last part of the vPC & Indeni series. We have talked about the guidelines and the methodology from the Indeni scripting language as well as the metrics from the cool features and powerful capabilities of the NX-OS vPC technology.We have gone over the great scripting capabilities of the Nexus switches which provide programmatic access to the switch CLI to perform various tasks. Python supports both interactive and non-interactive (script) modes. We successfully created and tested scripts to the Nexus 5000 series switch.
Taking advantage of the great NX-OS scripting capabilities and indeni script you can create your own scripts and powerful commands to the Nexus switches!
Learn more by joining the Indeni Community. If you liked this article please share it by clicking on one of the social media sharing icons at the top of this page. Thank you to Vasileios Bouloukos for his contributions to this article.