Overview

Programmability Overview

The Cisco NX-OS software running on the Cisco Nexus 9000 Series switches is as follows:

  • Resilient

    Provides critical business-class availability.

  • Modular

    Has extensions that accommodate business needs.

  • Highly Programmatic

    Allows for rapid automation and orchestration through Application Programming Interfaces (APIs).

  • Secure

    Protects and preserves data and operations.

  • Flexible

    Integrates and enables new technologies.

  • Scalable

    Accommodates and grows with the business and its requirements.

  • Easy to use

    Reduces the amount of learning required, simplifies deployment, and provides ease of manageability.

With the Cisco NX-OS operating system, the device functions in the unified fabric mode to provide network connectivity with programmatic automation functions.

Cisco NX-OS contains Open Source Software (OSS) and commercial technologies that provide automation, orchestration, programmability, monitoring, and compliance support.

For more information on Open NX-OS, see https://developer.cisco.com/site/nx-os/.

Supported Platforms

Starting with Cisco NX-OS release 7.0(3)I7(1), use the Nexus Switch Platform Support Matrix to know from which Cisco NX-OS releases various Cisco Nexus 9000 and 3000 switches support a selected feature.

Standard Network Manageability Features

  • SNMP (V1, V2, V3)

  • Syslog

  • RMON

  • NETCONF

  • CLI and CLI scripting

Advanced Automation Features

The enhanced Cisco NX-OS on the device supports automation. The platform includes support for Power On Auto Provisioning (POAP).

The enhanced Cisco NX-OS on the device supports automation. The platform includes the features that support automation.

Power On Auto Provisioning Support

Power On Auto Provisioning (POAP) automates the process of installing and upgrading software images and installing configuration files on switches that are being deployed in the network for the first time. It reduces the manual tasks that are required to scale the network capacity.

When a switch with the POAP feature boots and does not find the startup configuration, the device enters POAP mode. It locates a DHCP server and bootstraps itself with its interface IP address, gateway, and DNS server IP addresses. The device obtains the IP address of a TFTP server or the URL of an HTTP server and downloads a configuration script that enables the device to download and install the appropriate software image and configuration file.

XMPP Support

The enhanced NX-OS on Nexus 9000 family of switches integrates an XMPP client into the operating system. This allows a Nexus 9000 switch to be managed and configured with XMPP enabled chat clients. (Chat clients are commonly used for communication among users). The XMPP support enables certain useful capabilities:

  • Group configuration

    When you add a set of Nexus 9000 devices into a chat group, you can manage a set of Nexus 9000 switches as a group. This is useful to push certain common configurations to a set of Nexus 9000 devices, instead of configuring the devices individually.

  • Single point of management

    The XMPP server can act as a single point of management. When you authenticate against a single XMPP server, you gain access to all the devices registered on the server.

  • Security

    The XMPP interface supports role-based access control. It ensures that users execute only the commands they are authorized for.

  • Automation

    XMPP is a standards-based interface. The interface allows scripts and management tools to automate the management of Nexus 9000 devices.

Chef and Puppet Integration

Chef and Puppet are two intent-based infrastructure automation frameworks.

Chef allows you to define your intent with a recipe. A recipe is a reusable set of configuration or management tasks. Chef allows the recipe to be deployed on numerous devices. When deployed on a switch, a recipe translates into a network configuration or a set of commands for gathering statistics and analytics information. A recipe provides a way for automated configuration and management of a switch.

Puppet provides a similar intent definition construct that is called a manifest. When deployed on a switch, a manifest translates into a network configuration or a set of commands for gathering information from the switch.

The switch supports both the Puppet and Chef frameworks. The Puppet client and the Chef client are both integrated into the enhanced Cisco NX-OS on the switch.

OpenDayLight Integration and OpenFlow Support

Cisco Nexus switches support integration with the open source OpenDayLight project. OpenDayLight helps meet some of the requirements of operators and application developers for infrastructure:

  • Real-time orchestration and operation of integrated virtual compute, application, and network.

  • Simple interface to the network. An underlying detail such as a router, switch, or topology can be made abstract and more simple.

For OpenDayLight orchestration of Cisco Nexus switches, support is also available for other programmatic interfaces, such as NETCONF, that OpenDaylight can use in the southbound flow.

Cisco Nexus switches also support OpenFlow to enable use cases such as network TAP aggregation.

Programmability Support

Cisco NX-OS software on switches support several capabilities to aid programmability.

NX-API Support

Cisco NX-API allows for HTTP-based programmatic access to the switches. This support is delivered by NX-API, an open source webserver. NX-API provides the configuration and management capabilities of the Cisco NX-OS CLI with web-based APIs. The device can be set to publish the output of the API calls in XML or JSON format. This API enables rapid development on the switches.

Python Scripting

Cisco NX-OS supports Python v2.7.5 in both interactive and noninteractive (script) modes.

Beginning in Cisco NX-OS Release 9.3(5), Python 3 is also supported.

The Python scripting capability on the devices provides programmatic access to the switch CLI to perform various tasks, and to Power-On Auto Provisioning (POAP) and Embedded Event Manager (EEM) actions. Responses to Python calls that invoke the Cisco NX-OS CLI return text or JSON output.

The Python interpreter is included in the Cisco NX-OS software.

Tcl Scripting

Cisco Nexus 9000 Series switches support Tcl (Tool Command Language). Tcl is a scripting language that enables greater flexibility with CLI commands on the switch. You can use Tcl to extract certain values in the output of a show command, perform switch configurations, run Cisco NX-OS commands in a loop, or define EEM policies in a script.

Broadcom Shell

The Cisco Nexus 9000 Series switch front panel and fabric module line cards contain Broadcom Network Forwarding Engine (NFE). You can access the Broadcom command-line shell (bcm-shell) from these NFEs.

Bash

Cisco Nexus switches support direct Bourne-Again Shell (Bash) access. With Bash, you can access the underlying Linux system on the device and manage the system.

Bash Shell Access and Linux Container Support

Cisco Nexus switches support direct Linux shell access and Linux containers. With Linux shell access, you can access the underlying Linux system on the switch and manage the underlying system. You can also use Linux containers to securely install your own software and to enhance the capabilities of the Cisco Nexus switch. For example, you can install bare-metal provisioning tools like Cobbler on a Cisco Nexus switch to enable automatic provisioning of bare-metal servers from the top-of-rack switch.

Guest Shell

In process-hosted deployments, a virtual service execution environment (VSEE) isolates the onePK application from core routing and switching applications that the NOS provides; the environment also isolates its contents from other virtual services on the same host. The Application Developer can allocate specified quantities of CPU time, memory, disk space, and other resources to any particular VSEE.

Cisco utilizes the Cisco Secure Development Lifecycle (SDLC) to develop onePK applications that run in VSEEs on closed Cisco systems. The SDLC comprises a continuously evolving set of industry-recognized best practices and tools (including Cisco-proprietary tools) that reduce the vulnerability footprint of Cisco-provided applications, VSEEs, and platforms. These practices include the use of runtime checks that ensure the integrity of Cisco-signed binaries before loading them, and the establishment of a trust domain in which Cisco-provided onePK applications are allowed to run as trusted processes.

onePK applications in a VSEE communicate with the network element using onePK APIs that the onePK SDK provides. A secure communications channel carries messages between the VSEE and the onePK server. The use of the trust domain ensures the integrity of interprocess communications within the Cisco-provided VSEE, and additional security measures protect communications between the VSEE and the Cisco host.

The Network Administrator exercises direct control over the deployment of VSEEs and applications that interact with network elements. The duties of the Network Administrator include responsibility for verifying the integrity and validity of application packages. Cisco provides information (such as digital signatures or MD5 checksums) that enable Network Administrators to use standard software development tools to verify the integrity of application packages before deploying them. In addition, the default settings of the onePK VSEE security infrastructure allow only Cisco-signed application packages to run in process-hosted mode. To allow the deployment of unsigned containers or those containers that signed by third parties, the Network Administrator must take explicit action.

Because onePK allows low-level access to network elements, the Network Administrator must be very selective about user profiles and applications that are given access to onePK.

The Cisco Nexus 9000 Series switches support a virtual service environment that runs inside a secure Linux container (LXC). It isolates the application running in the guest shell of the virtual service environment from other routing and switching applications that the host Cisco NX-OS provides. The environment also isolates its contents from other virtual services on the same host. You can allocate specified quantities of CPU time, memory, disk space, and other resources to any particular virtual service environment.

Cisco utilizes the Cisco Secure Development Lifecycle (SDLC) to develop applications that run in virtual service environments on Cisco Nexus 9000 Series devices. The SDLC comprises a continuously evolving set of industry-recognized best practices and tools (including Cisco-proprietary tools) that reduce the vulnerability footprint of Cisco-provided applications, virtual service environments, and platforms. These practices include the use of runtime checks that ensure the integrity of Cisco-signed binaries before loading them, and the establishment of a trust domain in which Cisco-provided applications are allowed to run as trusted processes.

Applications in a guest shell communicate with the network using APIs. A secure communications channel carries messages between the guest shell and the device. The use of the trust domain ensures the integrity of interprocess communications within the Cisco-provided guest shell, and additional security measures protect communications between the guest shell and the device.

A network administrator controls the deployment of virtual service environments and applications that interact with the network. The duties of a network administrator include the responsibility for verifying the integrity and validity of application packages. Cisco provides information (such as digital signatures or MD5 checksums) that enable network administrators to use standard software development tools to verify the integrity of application packages before deploying them. In addition, the default settings of the guest shell security infrastructure allow only Cisco-signed application packages to run on the host. To allow the deployment of unsigned containers or those containers that are signed by third parties, the network administrator must take explicit action.

The Cisco Nexus 9000 Series switches support a guest shell that provides Bash access into a Linux execution space on the host system that is decoupled from the host Cisco Nexus 9000 NX-OS software. With the guest shell, you can add software packages and update libraries as needed without impacting the host system software.

Applications running in the guest shell have IP connectivity to the host system and the external network through socket APIs.

The guest shell is implemented as a secure Linux container (LXC) and is started automatically when the host system is started. This allows applications in the guest shell to be automatically started when the system is started. The amount of CPU, memory, and bootflash space used for the guest shell can be tuned to balance the resource usage between the guest shell and the host system. The guest shell mounts the system's bootflash to allow access to files on the bootflash using Linux commands.

Container Tracker Support

Cisco NX-OS is configured to communicate with the Kubernetes API Server to understand the capabilities of the containers behind a given switch port.

The following commands communicate with the Kubernetes API Server:

  • The show containers kubernetes command obtains data from kube-apiserver using API calls over HTTP.

  • The kubernetes watch resource command uses a daemon to subscribe to requested resources and process streaming data from kube-apiserver.

  • The action assigned in the watch command is performed on pre-defined triggers. (For example, Add or Delete of a Pod.)

Perl Modules


Note

Beginning with Cisco NX-OS Release 9.2(2), support for the Perl modules has been added for the Cisco Nexus 9504 and 9508 switches with -R line cards.

In order to support more applications, the following Perl modules have been added:

  • bytes.pm

  • feature.pm

  • hostname.pl

  • lib.pm

  • overload.pm

  • Carp.pm

  • Class/Struct.pm

  • Data/Dumper.pm

  • DynaLoader.pm

  • Exporter/Heavy.pm

  • FileHandle.pm

  • File/Basename.pm

  • File/Glob.pm

  • File/Spec.pm

  • File/Spec/Unix.pm

  • File/stat.pm

  • Getopt/Std.pm

  • IO.pm

  • IO/File.pm

  • IO/Handle.pm

  • IO/Seekable.pm

  • IO/Select.pm

  • List/Util.pm

  • MIME/Base64.pm

  • SelectSaver.pm

  • Socket.pm

  • Symbol.pm

  • Sys/Hostname.pm

  • Time/HiRes.pm

  • auto/Data/Dumper/Dumper.so

  • auto/File/Glob/Glob.so

  • auto/IO/IO.so

  • auto/List/Util/Util.so

  • auto/MIME/Base64/Base64.so

  • auto/Socket/Socket.so

  • auto/Sys/Hostname/Hostname.so

  • auto/Time/HiRes/HiRes.so