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:
|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:
This section describes in brief the methodology for the vPC NX-OS metrics, alert/analysis logic, live config and how all these are dynamically updated by periodically receiving the relevant CISCO NX-OS input.
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.
#! 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"
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.
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> ]]>]]>
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-type-2-consistency>consistent</vpc-type-2-consistency>||nexus-vpc-type-2-consistency||1|0||0 if (!consistent)|
|<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)|
As soon as this information has been collected and finalized the next step is to author and test the ind script. Now, it’s time to use your programming skills to write the vPC ind script which will get periodically all the aforementioned metrics. All of the contributed knowledge code is stored in a git repository called “indeni-knowledge“. Git has been selected due to it being powerful and allowing distributed teams to work together and collaborate. Very useful information is also provided via the Confluence. Finally, the Indeni crowd community and Indeni Knowledge experts are available to support you on this task!
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|
To get access to the python NX-OS embedded environment you must execute the “python” NX-OS command. As is illustrated in the next table after executing the aforementioned command you get the prompt to the python environment and the hash (#) command prompt is replaced by this symbol “>>>”. Now it is possible to directly execute python commands and scripts to the NX-OS.
N5k-DOWN# python Copyright (c) 2001-2012 Python Software Foundation; All Rights Reserved N5k-DOWN# >>>
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:
Python commands in interactive mode can be executed after switching to the python environment. Then we get the print output “I love Automation with Indeni” as is illustrated to next capture.
N5k-DOWN# >>> print "I love Automation with Indeni" I love Automation with Indeni N5k-DOWN# >>>
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.
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)...
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:
N5k-DOWN# dir bootflash:scripts | i hello 108 May 13 20:02:57 2017 helloIndeni.py
The content of the basic script is provided below.
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
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
N5k-Down# source helloIndeni.py indeni Hello indeni
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.
N5k-Down(config)# cli alias name hello source helloindeni.py N5k-Down# hello indeni Hello indeni
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.
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
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.
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
Finally, the script is executed as is illustrated to the next command:
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
Finally, the description is successfully configured to the interfaces as is shown to the output below:
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 ***
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.