Open Nx-os

[Latarsha Dorrance]

Automatedworkflows and virtualization technologies have led to dramatic improvements in data center scale, agility, and efficiency. Application developers, server administrators, and Cloud and DevOps teams have been utilizing the processes and tools around automation for many years, resulting in streamlined and less error prone workflows. These teams are able to keep up with the speed of business requirements and market transitions due to modern workflows. Leveraging open development frameworks has been essential for innovation.

Enter Open NX-OS on the Cisco Nexus platform, a rich software suite built on a Linux foundation that exposes APIs, data models, and programmatic constructs. Using Application Programmatic Interfaces (APIs) and configuration agents, operators can affect configuration changes in a more programmatic way.

This book explores Open NX-OS and many of the tools and options it provides. The chapters below examine the drivers for network automation, the fundamental supporting technologies, and the many new capabilities now available to network infrastructures. Real-world use cases are provided that can be immediately utilized for a successful transition to more efficient, safer, repeatable operations.

Within the introduction, we provide an initial walkthrough of the sections and chapters of this book. We try to highlight some important industry trends like the emergence of highly distributed applications and the adoption of Cloud and DevOps methodologies that are driving new paradigms in the network.

This primary section emphasizes how Open NX-OS based networking devices expose the full capability of the Linux operating system for end-users to utilize. Readers can learn how standard Linux tools like ifconfig, ethtool, route, tcpdump can be used to manage a Cisco Nexus Switch. Further, we help readers understand how they can extend the functionality of their switch with their own RPMs and containers, and unlock innovative new use cases.

This section provides an overview of the evolution of interfaces on networking devices from being human-centric to being programmabilty- friendly. It introduces the readers to some easy-to-use programmatic interfaces like NX-API CLI and helps them get started down the path of programmability.

This section explores the advantages of a model-driven approach to programmability, and highlights the powerful, new capabilities in Cisco NX-API REST, being a data model-backed RESTful API, brings to the table.

Infrastructure and network automation, driven by programmability, is a key enabler for the DevOps transformation. This chapter highlights the broad set of tools, features and capabilities that Open NX-OS incorporates to enable automation. The discussion covers integration with modern config management tools like Puppet, Chef and Ansible.

This section shifts the focus from description of network programmability and automation technologies to practical applications of these technologies. Although not exhaustive, the use-cases showcase real solutions intended to spark ideas for new innovative deployments. Each use-case is presented in the following format:

This section explores essential tools for network programming as well as the underlying languages and environments. An introduction to Cisco DevNet for Open NX-OS is provided for developers and users to explore the capabilities of Open NX-OS.

The intended audience for this book are those persons with a general need to understand how to utilize network programmability and unleash the power behind the Open NX-OS architecture. While interested development and IT practitioners may reap the most benefits from this content, the information and examples included within this book may be of use for every intermediate to advanced network professional interested in programmable fabrics.

Elements in this book explore topics beyond the traditional responsibility of a network administrator. The modular and extensible framework of the Open NX-OS modular architecture is not only discussed, but also exemplified through the ability to programmatically configure, operate, and manage Cisco Nexus switches as Linux servers and beyond.

Ten In, One Out: Ten individually-selected highly-skilled professionals from diverse backgrounds accepted the challenge to duel thoughts over the course of five days. Figuring out how to harness the brain power and collaborate effectively seemed to be nearly impossible, however opposites attracted and the team persisted through the hurdles. The Book Sprint methodology captured each of our strengths, fostered a team-oriented environment and accelerated the overall time to completion. The assembled group leveraged their near two hundred years of experience and a thousand hours of diligent authorship which resulted in this publication.

In this sample chapter from Containers in Cisco IOS-XE, IOS-XR, and NX-OS: Orchestration and Operation, you will explore the key built-in capabilities that enable application hosting and containers in Nexus switching platforms.

In addition to the NX-OS CLI, Cisco Nexus 9000 Series devices support access to Bash. Bash interprets commands that you enter or commands that are read from a shell script. It enables access to the underlying Linux kernel on the device and to manage the system.

In the supported platforms, under configuration mode, the feature bash-shell command enables this feature with no special license required. Use the show bash-shell command to learn the current state of the feature, as shown in Example 7-19.

For users without network-admin or dev-ops level privileges, the run bash command will not be parsed, and when executed, the system will report that permission has been denied. As you see in Example 7-22, the testuser with the privilege level not set to network-admin or dev-ops has its permission to execute the run bash command denied.

If you SSH to the switch using the root username through a nonmanagement interface, it will default to Linux Bash shell-type access for the root user. If a user has established an SSH connection directly to Bash and needs to access NX-OS, use vsh commands, as shown in Example 7-26.

Beginning with Release 9.2(1), support has been included for using Docker within the Cisco NX-OS switch. The version of Docker that is included on the switch is 1.13.1. By default, the Docker service or daemon is not enabled. You must start it manually or set it up to automatically restart when the switch boots up.

Even though the scope of this book does not intend to cover Docker in detail, it is good to take a quick look at the key components in the Docker architecture and their functions, as illustrated in Figure 7-6.

The Docker client enables end users to interact with the Docker host and the daemons running on it. The Docker client can be on a dedicated device or can reside on the same device as a host. A Docker client can communicate with multiple daemons running on multiple host devices. The Docker client provides a CLI and REST APIs that allow users to issue build, run, and stop application commands to a Docker daemon. The main purpose of the Docker client is to provide a means to direct pulling images from a registry and having them run on a Docker host.

The Docker host provides an environment dedicated to executing and running applications. The key component is a Docker daemon that interacts with the client as well as the registry and with containers, images, the network, and storage. This daemon is responsible for all container-related activities and carrying out the tasks received via CLIs or APIs. The Docker daemon pulls the requested image and builds containers as requested by the client, following the instructions provided in a build file.

As has been discussed in previous chapters, containers are self-contained environments in which you run applications. The container is defined by the image and any additional configuration parameters provided during its instantiation. These configuration parameters are used to identify the file systems and partitions to mount, to set specific network mode, and so on.

Please be aware that when the Docker daemon is started for the first time, 2 GB of storage space is carved out for a file called dockerpart in the bootflash filesystem. This file will be mounted as /var/lib/docker. If needed, the default size of this space reservation can be changed by editing /etc/sysconfig/docker before you start the Docker daemon for the first time.

Example 7-29 shows instantiating an Alpine Linux Docker container on the switch, which is, by default, launched in the host network mode. The Docker containers instantiated in the bridged networking mode have external network connectivity but do not necessarily care about the visibility into or access to ports in the host. Note that the containers operating in bridged networking mode are far more secure than the ones operating in host networking mode.

If you want to mount a specific file system or partitions, use the -v option, as shown in Example 7-31, when you launch the container. The Bootflash file system will be mounted into and accessible only from the myalpine1 container; it will not be available from myalpine, which was instantiated without mounting the Bootflash file system.

Beyond instantiating and activating containers with applications installed, you need to know how to manage the containers. Container management becomes critical when containers are deployed at scale. This section discusses managing containers deployed in the Nexus switches, and associated techniques.

With the previous commands, you have made the Alpine Linux container restart. As shown in Example 7-33, use the chkconfig utility to make the service persistent, before the supervisor engine switchover. Then copy the dockerpart file created in the active supervisor engine to standby.

3a8082e126