The Guest Shell container allows users to run their scripts and apps on the system. The Guest Shell container on Intel platforms will be a Linux container (LXC) with a Centos 7.0 minimal rootfs. Python Version 2.7.11 is pre-installed in this container. Users can install Python Version 3.0 during runtime using the Yum utility in Centos 7.0.

The Guest Shell container on Advanced RISC Machines (ARM) and MIPS platforms will be Carrier Grade Edition (CGE) 7.0 container that has Python Version 2.7.11 pre-installed.

Applications running in third-party containers and the Guest Shell must comply with the UAPI provided by the host Linux kernel.

The rootfs can be installed on a flash file sytem or any other persistent storage device as a Linux container.

The choice of rootfs for a platform depends on the CPU architecture and storage resources available on the platform. On X86 and ARM CPU architectures, preference is given to CentOS/Debian Linux rootfs. For other CPU architectures and platforms with limited resources, a Montavista-based rootfs with software built from Yocto system is available. Cisco provides RPM packages for software that can be dynamically installed in the Guest Shell. Cisco provided RPM is only for CentOS distribution.

Rootfs is packaged with Cisco IOS XE Everest 16.5.x image as a subpackage and the subpackage can be upgraded through install commands. For more information, see the In Service Model Update feature.

Cisco provides security to ensure that users or apps in the Guest Shell do not compromise the host system. To isolate the container or Guest Shell from the host, usernamespaces are used on the host kernel. With usernamespace support, the container or Guest Shell runs as an unprivileged container.

Cisco also uses SELinux to contain and isolate attacks from arbitrary third-party applications that users may run in the container or the Guest Shell. SELinux is a third-party kernel Linux Security Module (LSM) that allows the isolation of applications/containers at a granular level.

In Cisco Catalyst 3000 Series Switches, a single software bundle is supported for multiple stock keeping units (SKUs). The following table is to highlight that the image size is constrained to the bootflash of the smallest SKU. Therefore accounting for the supported deployment models, we capture the storage requirements below:

Network administrators can use IOS commands to manage files and utilities in the Guest Shell. Guest Shell access is provided using the SSH service running in the Linux container on the loopback interface on the management virtual routing and forwarding (VRF) instance.

During the Guest Shell installation, SSH access is setup with a key-based authentication. The access to the Guest Shell is restricted to the user with the highest privilege in IOS. This user is granted root access into the Linux container. When the user accesses the Guest Shell, an IOS authentication token is provided in the environment variable of the Guest Shell session. This token is used to access the Plug N Play (PnP) agent without using an username or a password. Commands sent in PnP requests are executed with same privilege that the user had when logged into the IOS terminal. To access Device Management Instrumentation (DMI) services from the Linux container, username and password are required.

Note	Management networking is supported only on Cisco Catalyst 3650 Series Switches and Cisco Catalyst 3850 Series Switches.

Guest Shell allows applications to access the management network by default. To support zero-touch configuration through the management network, and to save the management IP address, the host management network namespace, the management virtual routing and forwarding (VRF) instance, and VRF 2 namespace of the host Linux container is mounted onto the Guest Shell. Network administrators/users can switch to the Guest Shell inside the container to access the management network.

All management networking services must start in this VRF 2 namespace from the Guest Shell. However, port conflicts between services started inside the container and services started from the host device can occur. In case of port conflicts, a different port number must be used when the service is started from the container.

To enable management networking, the VRF 2 namespace must be bind mounted onto the corresponding Guest Shell rootfs, before the Guest Shell is activated. The mount point must be unmounted after the Guest Shell is deactivated.

Users cannot change the management VRF networking configurations from inside the container.

Note	For platforms without a management port, a virtual port group can be associated with Guest Shell in the IOS configuration.

Cisco application hosting framework (CAF) is an IOx Python process that manages virtualized and container applications running on devices. Guest Shell is a specific application for CAF that is installed and managed from IOS commands. The Guest Shell container is started by configuring the iox command.

The lifecycle of Guest Shell is managed by CAF, and for CAF to install the Guest Shell, the contents must be an IOx application package. The IOx application package for Guest Shell is in the TAR file format. The CAF-formatted tar file (guest_shell.tar) content for Guest Shell is packaged into the Cisco IOS XE Everest 16.5.x image.

During the initialization of Cisco devices, the Guest Shell package content is mounted onto the root file system of the host system (under the /tmp/sw/isos or an equivalent directory), and the Guest Shell package is made available for CAF to install rootfs on the non-volatile bootflash. After the Guest Shell package is installed, if a newer version of the Guest Shell rootfs is available, CAF will install it from the image during a reload.

The following are the contents of the application TAR file:

• A package descriptor file, named package.yaml that is present in the root directory.

• Zero or one application configuration file, named package_config.ini. This file, if present, must be in the root directory.

• An application manifest, named package.mf that is present in the root directory.

• Zero or one tar.gz envelop that contains application artifacts, named artifacts.tar.gz. These artifacts can be binaries, application code, application libraries, virtual disks, rootfs and so on.

Note	Cisco Catalyst 3650 Series Switches and Cisco Catalyst 3850 Series Switches do not support application hosting.

Cisco application hosting framework (CAF) is an IOx Python process that manages virtualized and container applications running on devices. CAF provides the following services:

• Launches designated applications (like a Cisco Guest Shell) in containers.

• Checks available resources (memory, CPU, and storage), and allocate and manage them.

• Provides support for console logging.

• Provides access to relevant services via REST APIs.

• Provides a CLI endpoint.

• Provides a TDL-enabled message path for CAF.

• Helps in the setup of platform-specific networking (packet-path) via virtual port group (VPG) interfaces and Linux Shared Memory Punt Interface (LSMPI) or LFTS-based interception.

To ensure security and stability, Linux containers are used to deploy signed applications, and Kernel-based Virtual Machine (KVM) containers are used to deploy applications trusted by users.

Applications to be deployed in the containers are packaged as TAR files. The configuration that is specific to the application to be deployed in the container is also packaged as a TAR file. Applications, such as the Guest Shell, can be deployed to a system using a local store (for the TAR file), or via the Internet through Cisco Fog Services in conjunction with the Cisco Developer Network.

To manage IOx, a local Web Management Interface (Local Manager) and a multi-device remote application manager are available. The Local Manager management interface enables application life cycle management on the local IOx device. The remote manager can manage multiple IOx devices, and can perform bulk operations that manages the life cycle of an IOx application.

The guestshell enable command installs Guest Shell from a Guest Shell software package. By default, the package embedded in the system image is used for the installation. If Guest Shell is not installed, this command extracts the Guest Shell image from the system image. This command is also used to reactivate Guest Shell, if it is disabled.

When Guest Shell is enabled and the system is reloaded, Guest Shell remains enabled.

Note	IOx should be configured before the guestshell enable command is used.

The guestshell run command opens the Guest Shell bash prompt. Guest Shell must already be enabled for this command to work.

The guestshell disable command shuts down and disables Guest Shell. When Guest Shell is disabled and the system is reloaded, Guest Shell remains disabled.

The guestshell destroy command removes the rootfs from the flash filesystem.