Third-Party Applications

This chapter contains the following sections:

About Third-Party Applications

The RPMs for the Third-Party Applications are available in the repository at https://devhub.cisco.com/artifactory/open-nxos/7.0-3-I2-1/x86_64/https://devhub.cisco.com/artifactory/open-nxos/9.2.1/. These applications are installed in the native host by using the yum command in the Bash shell or through the NX-OS CLI.

When you enter the yum install rpm command, a Cisco YUM plug-in gets executed. This plug-in copies the RPM to a hidden location. On switch reload, the system reinstalls the RPM.

For configurations in /etc, a Linux process, incrond , monitors artifacts that are created in the directory and copies them to a hidden location, which gets copied back to /etc.

Guidelines and Limitations

RPMs for the third-party applications have the following guidelines and limitations:

  • Starting with Cisco NX-OS Release 9.2(1), the Cisco repository where agents are stored is now located at https://devhub.cisco.com/artifactory/open-nxos/9.2.1/. All RPMs hosted in this repository are signed with the release key.

  • The NX-OS 9.2(1) release has a new operating system and rootfs, based on Wind River Linux 8 (WRL8), so third-party RPMs that were built using WRL5 might not be compatible with WRL8, so the third-party software might not work. In this case, remove old versions of your apps used with previous releases and replace them with new software that is compatible with WRL8, which is available in the repository at https://devhub.cisco.com/artifactory/open-nxos/9.2.1/

  • Guidelines and instructions for installing signed RPMs are provided in the Cisco Nexus 9000 Series NX-OS Software Upgrade and Downgrade Guide, Release 9.2(x), including YUM and VSH CLI options for managing RPMs, signed and nonsigned RPM installations, the clean-up of repositories, and so on.

  • The third-party applications are started during switch startup. It is possible that a third-party application could be started before its communication interface is up, or before the routing between the switch and any communication peer or server is established. Therefore, all third-party applications should be written to be robust in case of communication failure, and the application should retry establishing the connection. If an application is not resilient in the presence of a communication failure, a “wrapper” application might be required to establish that any communication peer is reachable before starting the desired application, or restart the desired application if necessary.

Installing Third-Party Native RPMs/Packages

The complete workflow of package installation is as follows:

Procedure


Configure the repository on the switch to point to the Cisco repository where agents are stored.

bash-4.2# cat /etc/yum/repos.d/open-nxos.repo 
[open-nxos]
name=open-nxos
baseurl=https://devhub.cisco.com/artifactory/open-nxos/7.0-3-I2-1/x86_64/
baseurl=https://devhub.cisco.com/artifactory/open-nxos/9.2.1/

enabled=1
gpgcheck=0
sslverify=0

Instructions for using the CLIs to import the digital signature are available in the section "Using Install CLIs for Digital Signature Support" in the Cisco Nexus 9000 Series NX-OS Software Upgrade and Downgrade Guide, Release 9.2(x).

An example of installation of an RPM using yum , with full install log.

Example:

bash-4.2# yum install splunkforwarder
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching, protect-packages
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package splunkforwarder.x86_64 0:6.2.3-264376 will be installed
--> Finished Dependency Resolution
 
Dependencies Resolved
 
=============================================================================================
 Package              Arch                 Version           Repository             Size
=============================================================================================
Installing:
splunkforwarder       x86_64               6.2.3-264376      open-nxos              13 M
 
Transaction Summary
=============================================================================================
Install       1 Package
 
Total size: 13 M
Installed size: 34 M
Is this ok [y/N]: y
Downloading Packages:
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing : splunkforwarder-6.2.3-264376.x86_64                                                                                                                      1/1 
complete
 
Installed:
  splunkforwarder.x86_64 0:6.2.3-264376                                                                                                                                     
 
Complete!
bash-4.2# 
 

An example of querying the switch for successful installation of the package, and verifying that its processes or services are up and running.

Example:

bash-4.2# yum info splunkforwarder
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching, protect-packages
Fretta              |  951 B     00:00 ... 
groups-repo         | 1.1 kB     00:00 ... 
localdb             |  951 B     00:00 ... 
patching            |  951 B     00:00 ... 
thirdparty          |  951 B     00:00 ... 
Installed Packages
Name        : splunkforwarder
Arch        : x86_64
Version     : 6.2.3
Release     : 264376
Size        : 34 M
Repo        : installed
From repo   : open-nxos
Summary     : SplunkForwarder
License     : Commercial
Description : The platform for machine data.

Persistent Third-Party RPMs

The following is the logic behind persistent third-party RPMs:

  • A local yum repository is dedicated to persistent third-party RPMs. The /etc/yum/repos.d/thirdparty.repo points to /bootflash/.rpmstore/thirdparty.

  • Whenever you enter the yum install third-party.rpm command, a copy of the RPM is saved in //bootflash/.rpmstore/thirdparty.

  • During a reboot, all the RPMs in the third-party repository are reinstalled on the switch.

  • Any change in the /etc configuration files persists under /bootflash/.rpmstore/config/etc and they are replayed during boot on /etc.

  • Any script that is created in the /etc directory persists across reloads. For example, a third-party service script that is created under /etc/init.d/ brings up the apps during a reload.


    Note


    The rules in iptables are not persistent across reboots when they are modified in a bash-shell.

    To make the modified iptables persistent, see Making an Iptable Persistent Across Reloads.


Installing RPM from VSH

Package Addition

NX-OS feature RPMs can also be installed by using the VSH CLIs.

Procedure

  Command or Action Purpose

Step 1

show install package

Displays the packages and versions that already exist.

Step 2

install add ?

Determine supported URIs.

Step 3

install add rpm-packagename

The install add command copies the package file to a local storage device or network server.

Example

The following example shows how to activate the Chef RPM:

switch# show install package
switch# install add ?
WORD        Package name
bootflash:  Enter package uri
ftp:        Enter package uri
http:       Enter package uri
modflash:   Enter package uri
scp:        Enter package uri
sftp:       Enter package uri
tftp:       Enter package uri
usb1:       Enter package uri
usb2:       Enter package uri
volatile:   Enter package uri
switch# install add bootflash:chef-12.0.0alpha.2+20150319234423.git.1608.b6eb10f-1.el5.x86_64.rpm
[####################] 100%
Install operation 314 completed successfully at Thu Aug  6 12:58:22 2015

What to do next

When you are ready to activate the package, go to Package Activation.


Note


Adding and activating an RPM package can be accomplished in a single command:

switch# 
install add bootflash:chef-12.0.0alpha.2+20150319234423.git.1608.b6eb10f-1.el5.x86_64.rpm activate

Package Activation

Before you begin

The RPM has to have been previously added.

Procedure

  Command or Action Purpose

Step 1

show install inactive

Displays the list of packages that were added and not activated.

Step 2

install activate rpm-packagename

Activates the package.

Example

The following example shows how to activate a package:

switch# show install inactive
Boot image:
        NXOS Image: bootflash:///yumcli6.bin

Inactive Packages:
        sysinfo-1.0.0-7.0.3.x86_64
Loaded plugins: downloadonly, importpubkey, localrpmDB, patchaction, patching,
              : protect-packages
Available Packages
chef.x86_64       12.0.0alpha.2+20150319234423.git.1608.b6eb10f-1.el5 thirdparty
eigrp.lib32_n9000 1.0.0-r0                                            groups-rep
o
sysinfo.x86_64    1.0.0-7.0.3                                         patching
switch# install activate chef-12.0-1.el5.x86_64.rpm
[####################] 100%
Install operation completed successfully at Thu Aug  6 12:46:53 2015

Deactivating Packages

Procedure

Command or Action Purpose

install deactivate package-name

Deactivates the RPM package.

Example

The following example shows how to deactivate the Chef RPM package:

switch# install deactivate chef

Removing Packages

Before you begin

Deactivate the package before removing it. Only deactivated RPM packages can be removed.

Procedure

Command or Action Purpose

install remove package-name

Removes the RPM package.

Example

The following example shows how to remove the Chef RPM package:

switch# install remove chef-12.0-1.el5.x86_64.rpm

Displaying Installed Packages

Procedure

Command or Action Purpose

show install packages

Displays a list of the installed packages.

Example

The following example shows how to display a list of the installed packages:

switch# show install packages

Displaying Detail Logs

Procedure

Command or Action Purpose

show tech-support install

Displays the detail logs.

Example

The following example shows how to display the detail logs:

switch# show tech-support install

Upgrading a Package

Procedure

Command or Action Purpose

install add package-name activate upgrade

Upgrade a package.

Example

The following example shows how to upgrade a package:

switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate ?
downgrade  Downgrade package
forced     Non-interactive
upgrade    Upgrade package
switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate upgrade 
[####################] 100%
Install operation completed successfully at Thu Aug  6 12:46:53 2015

Downgrading a Package

Procedure

Command or Action Purpose

install add package-name activate downgrade

Downgrade a package.

Example

The following example shows how to downgrade a package:

switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate ?
downgrade  Downgrade package
forced     Non-interactive
upgrade    Upgrade package
switch# install add bootflash:bgp-1.0.1-r0.lib32_n9000.rpm activate downgrade 
[####################] 100%
Install operation completed successfully at Thu Aug  6 12:46:53 2015

Third-Party Applications

collectd

collectd is a daemon that periodically collects system performance statistics and provides multiple means to store the values, such as RRD files. Those statistics can then be used to find current performance bottlenecks (for example, performance analysis) and predict future system load (that is, capacity planning).

For additional information, see https://collectd.org.

Ganglia

Ganglia is a scalable distributed monitoring system for high-performance computing systems such as clusters and grids. It is based on a hierarchical design that is targeted at federations of clusters. It leverages widely used technologies such as XML for data representation, XDR for compact, portable data transport, and RRDtool for data storage and visualization. It uses engineered data structures and algorithms to achieve low per-node overheads and high concurrency. The implementation is robust, has been ported to an extensive set of operating systems and processor architectures, and is currently in use on thousands of clusters around the world. It has been used to link clusters across university campuses and around the world and can scale to handle clusters with 2000 nodes.

For additional information, see http://ganglia.info.

LLDP

The link layer discover protocol (LLDP) is an industry standard protocol that is designed to supplant proprietary link layer protocols such as EDP or CDP. The goal of LLDP is to provide an intervendor compatible mechanism to deliver link layer notifications to adjacent network devices.

For more information, see https://vincentbernat.github.io/lldpd/index.html.

Nagios

Nagios is open source software that monitors the following through the Nagios remote plug-in executor (NRPE) and through SSH or SSL tunnels:
  • Network services through ICMP, SNMP, SSH, FTP, HTTP, and so on

  • Host resources, such as CPU load, disk usage, system logs, and so on

  • Alert services for servers, switches, applications

  • Services

For more information, see https://www.nagios.org/.

OpenSSH

OpenSSH is an open-source version of the SSH connectivity tools that encrypts all traffic (including passwords) to eliminate eavesdropping, connection hijacking, and other attacks. OpenSSH provides secure tunneling capabilities and several authentication methods, and supports all SSH protocol versions.

For more information, see http://www.openssh.com.

Quagga

Quagga is a network routing software suite that implements various routing protocols. Quagga daemons are configured through a network accessible CLI called a "vty."


Note


Only Quagga BGP has been validated.


For more information, see http://www.nongnu.org/quagga/.

Splunk

Splunk is a web-based data collection, analysis, and monitoring tool that has search, visualization, and prepackaged content for use-cases. The raw data is sent to the Splunk server using the Splunk Universal Forwarder. Universal Forwarders provide reliable, secure data collection from remote sources and forward that data into the Splunk Enterprise for indexing and consolidation. They can scale to tens of thousands of remote systems, collecting terabytes of data with a minimal impact on performance.

For additional information, see http://www.splunk.com/en_us/download/universal-forwarder.html.

tcollector

tcollector is a client-side process that gathers data from local collectors and pushes the data to Open Time Series Database (OpenTSDB).

tcollector has the following features:

  • Runs data collectors and collates the data.

  • Manages connections to the time series database (TSD).

  • Eliminates the need to embed TSD code in collectors.

  • Deduplicates repeated values.

  • Handles wire protocol work.

For additional information, see http://opentsdb.net/docs/build/html/user_guide/utilities/tcollector.html.

tcpdump

tcpdump is a CLI application that prints a description of the contents of packets on a network interface that match a Boolean expression. The description is preceded by a timestamp, printed, by default, as hours, minutes, seconds, and fractions of a second since midnight.

tcpdump can be run with the following flags:
  • -w, which causes it to save the packet data to a file for later analysis.

  • -r, which causes it to read from a saved packet file rather than to read packets from a network interface.

  • -V, which causes it to read a list of saved packet files.

In all cases, tcpdump processes only the packets that match the expression.

For more information, see http://www.tcpdump.org/manpages/tcpdump.1.html.

TShark

TShark is a network protocol analyzer on the CLI. Tshar lets you capture packet data from a live network, or read packets from a previously saved capture file. You can print either a decoded form of those packets to the standard output or write the packets to a file. TShark's native capture file format is pcap, the format that is used by tcpdump and various other tools also. TShark can be used within the Guest Shell after removing the cap_net_admin file capability.

setcap
 cap_net_raw=ep /sbin/dumpcap

Note


This command must be run within the Guest Shell.


For more information, see https://www.wireshark.org/docs/man-pages/tshark.html.