Sonic Switch 2G Shell

Shell version: 1.1.3

Document version: 1.0

In This Guide

• Overview
• Downloading the Shell
• Importing and Configuring the Shell
• Updating Python Dependencies for Shells
• Typical Workflows
• References
• Release Notes

Overview

A shell integrates a device model, application or other technology with CloudShell. A shell consists of a data model that defines how the device and its properties are modeled in CloudShell, along with automation that enables interaction with the device via CloudShell.

Networking Shells

CloudShell's networking shells provide L2 or L3 connectivity between resources and/or Apps.

Sonic Switch 2G Shell

The Sonic Switch 2G shell provides you with connectivity and management capabilities such as device structure discovery and VLAN/VXLAN connectivity configuration for Celestica switches running SONiC OS.

For more information on Celestica's SONiC-based switches, see the official Celestica and SONiC product documentation.

Standard version

Sonic Switch 2G Shell is based on the Networking Shell Standard version 5.0.2.

For detailed information about the shell's structure and attributes, see the Networking Shell Standard in GitHub.

Requirements

Release: Sonic Switch 2G Shell

▪ CloudShell version: 2021.1 GA and above

▪ Python Version: 3

▪ Device OS: SONiC

▪ Certified models: Celestica SONiC-based switches

▪ CLI connectivity: SSH only (see Notes below)

Note: If your CloudShell version does not support this shell, you should consider upgrading to a later version of CloudShell or contact customer support.

Data Model

The shell's data model includes all shell metadata, families, and attributes.

Sonic Switch 2G Shell Families and Models

The Sonic Switch families and models are listed in the following table:

Family	Model	Description
CS_Switch	Sonic Switch 2G	Generic Celestica SONiC OS Switch 2 Generation
CS_Chassis	Generic Chassis	Default Switch chassis
CS_Module	Generic Module	Modules located on the chassis
CS_SubModule	Generic Sub Module	Sub modules
CS_Port	Generic Port	Interface
CS_PortChannel	Generic Port Channel	Group of interfaces
CS_PowerPort	Generic Power Port	Power Supply module

Sonic Switch 2G Shell Attributes

The attribute names and types are listed in the following section of the Networking Shell Standard:

https://github.com/QualiSystems/cloudshell-standards/blob/master/Documentation/networking_standard.md#attributes

Notes

• Autoload (SNMP-based) currently discovers Chassis and Port sub-resources only. Module, Sub Module, Port Channel and Power Port sub-resources are not populated by this shell's autoload.
• Although the Networking Shell Standard's CLI Connection Type attribute offers Auto, Console, SSH, Telnet and TCP, this shell's CLI handler registers an SSH session only. Set CLI Connection Type to SSH, or leave the connection details as-is if using the default — Telnet and Console are not implemented.
• SNMP Version defaults to v2c with SNMP Read/Write Community set to public. SNMP v3 is also supported via the SNMP V3 User, SNMP V3 Password and SNMP V3 Private Key attributes.
• The default User/Password values shipped in the shell's data model are placeholders — replace them with credentials valid for your device before running Autoload.

Automation

This section describes the automation (drivers) associated with the data model. The shell's driver is provided as part of the shell package. There are two types of automation processes, Autoload and Resource. Autoload is executed when creating the resource in the Inventory dashboard, while resource commands are run in the sandbox.

The following resource commands are available on the Sonic Switch:

• Run Custom Command
• Save
• Restore
• Apply Connectivity Changes (VLAN/VXLAN configuration)

For detailed information on the Save, Restore and Run Custom Command commands, see the following section of the Networking Shell Standard:

https://github.com/QualiSystems/cloudshell-standards/blob/master/Documentation/networking_standard.md#commands

Note: Load Firmware and Health Check are exposed on the driver's command layout for standard compliance, but are not currently implemented by this shell (they return without performing any action). Do not rely on them until a future revision implements this logic.

Downloading the Shell

The Sonic Switch 2G Shell shell comprises:

File name	Description
Sonic Switch 2G.zip	Sonic Switch shell package
Sonic-Switch-2G-offline-dependencies.zip	Shell Python dependencies (for offline deployments only)

Importing and Configuring the Shell

This section describes how to import the Sonic Switch 2G Shell shell and configure and modify the shell's devices.

Importing the shell into CloudShell

To import the shell into CloudShell:

1. Make sure you have the shell's zip package (see Downloading the Shell).

2. In CloudShell Portal, as Global administrator, open the Manage – Shells page.

3. Click Import.

4. In the dialog box, navigate to the shell's zip package, select it and click Open.
   
   The shell is displayed in the Shells page and can be used by domain administrators in all CloudShell domains to create new inventory resources, as explained in Adding Inventory Resources.

Offline installation of a shell

Note: Offline installation instructions are relevant only if CloudShell Execution Server has no access to PyPi. You can skip this section if your execution server has access to PyPi. For additional information, see the online help topic on offline dependencies.

In offline mode, import the shell into CloudShell and place any dependencies in the appropriate dependencies folder. The dependencies folder may differ, depending on the CloudShell version you are using:

• For CloudShell version 8.3 and above, see Adding Shell and script packages to the local PyPi Server repository.

Adding shell and script packages to the local PyPi Server repository

If your Quali Server and/or execution servers work offline, you will need to copy all required Python packages, including the out-of-the-box ones, to the PyPi Server's repository on the Quali Server computer (by default C:\Program Files (x86)\QualiSystems\CloudShell\Server\Config\Pypi Server Repository).

For more information, see Configuring CloudShell to Execute Python Commands in Offline Mode.

To add Python packages to the local PyPi Server repository:

1. If you haven't created and configured the local PyPi Server repository to work with the execution server, perform the steps in Add Python packages to the local PyPi Server repository (offline mode).

2. For each shell or script you add into CloudShell, do one of the following (from an online computer):

   • Connect to the Internet and download each dependency specified in the requirements.txt file with the following command: pip download -r requirements.txt. The shell or script's requirements are downloaded as zip files.

   • Extract the Sonic-Switch-2G-offline-dependencies.zip file, see Downloading the Shell.

3. Place these zip files in the local PyPi Server repository.

Setting the python PythonOfflineRepositoryPath configuration key

Before PyPi Server was introduced as CloudShell's python package management mechanism, the PythonOfflineRepositoryPath key was used to set the default offline package repository on the Quali Server machine, and could be used on specific Execution Server machines to set a different folder.

To set the offline python repository:

1. Download the Sonic-Switch-2G-offline-dependencies.zip file, see Downloading the Shell.

2. Unzip it to a local repository. Make sure the execution server has access to this folder.

3. On the Quali Server machine, in the ~\CloudShell\Server\customer.config file, add the following key to specify the path to the default python package folder (for all Execution Servers): <add key="PythonOfflineRepositoryPath" value="repository full path"/>

4. If you want to override the default folder for a specific Execution Server, on the Execution Server machine, in the ~TestShell\Execution Server\customer.config file, add the following key: <add key="PythonOfflineRepositoryPath" value="repository full path"/>

5. Restart the Execution Server.

Configuring a new resource

This section explains how to create a new resource from the shell.

In CloudShell, the component that models the device is called a resource. It is based on the shell that models the device and allows the CloudShell user and API to remotely control the device from CloudShell.

You can also modify existing resources, see Managing Resources in the Inventory.

To create a resource for the device:

1. In the CloudShell Portal, in the Inventory dashboard, click Add New.

2. From the list, select Sonic Switch 2G.

3. Enter the Name and IP address of the Sonic Switch.

4. Click Create.

5. In the Resource dialog box, enter the device's settings, see Sonic Switch 2G Shell Attributes. Make sure you enter the device's SNMP version and credentials, and that CLI Connection Type is set to SSH.

6. Click Continue.
   
   CloudShell validates the device's settings and updates the new resource with the device's structure (Chassis and Ports).

Updating Python Dependencies for Shells

This section explains how to update your Python dependencies folder. This is required when you upgrade a shell that uses new/updated dependencies. It applies to both online and offline dependencies.

Updating offline Python dependencies

To update offline Python dependencies:

1. Download the latest Python dependencies package zip file locally.

2. Extract the zip file to the suitable offline package folder(s).

3. Terminate the shell's instance, as explained here.

Updating online Python dependencies

In online mode, the execution server automatically downloads and extracts the appropriate dependencies file to the online Python dependencies repository every time a new instance of the driver or script is created.

To update online Python dependencies:

• If there is a live instance of the shell's driver or script, terminate the shell's instance, as explained here. If an instance does not exist, the execution server will download the Python dependencies the next time a command of the driver or script runs.

Typical Workflows

Workflow 1 - Save configuration

1. In CloudShell Portal, add the Sonic Switch resource to your blueprint and reserve the blueprint.

2. Run the Save resource command.

3. In the command inputs field, enter the following information:

   • Configuration Type: Startup or Running. Startup copies /etc/sonic/config_db.json; Running exports the live configuration via sonic-cfggen -d --print-data.
   • Folder Path: Optional. A destination such as sftp://user:password@host/path or scp://host/path. If omitted, the file is saved locally on the device under the connected user's home folder.
   • VRF Management Name: Provide the VRF Management name, if relevant.

4. Click Run.

The Startup or Running configuration is saved to a file named -<startup/running>-.json, either transferred to the folder path you entered or left on the device.

Workflow 2 - Restore configuration

1. In CloudShell Portal, add the Sonic Switch resource to your blueprint and reserve the blueprint.

2. Run the Restore resource command.

3. In the command inputs field, enter the following information:

   • Path: (Mandatory) The full path to the configuration file, for example sftp://user:password@host/path/config.json.
   • Restore Method: (Optional) Append merges the file with the current configuration using config load -y. Override (default) replaces /etc/sonic/config_db.json with the file and triggers config reload -y, which restarts SONiC's configuration and drops the SSH session — the shell automatically retries reconnecting (up to 20 attempts, 15 seconds apart) until the switch comes back up.
   • Configuration Type: (Mandatory) Startup or Running.
   • VRF Management Name: (Optional) Provide the VRF Management name, if relevant.

4. Click Run.

Workflow 3 - Apply connectivity changes (VLAN / VXLAN)

1. In CloudShell Portal, add the Sonic Switch resource to your blueprint, connect its ports to other resources/Apps in the topology, and reserve the blueprint.

2. Run Connect (or let orchestration trigger Apply Connectivity Changes) on the connection.

3. The shell resolves the CloudShell port names to SONiC interface names, creates the VLAN if needed, and adds the port as an untagged member for Access mode or a tagged member for Trunk mode. If the VLAN's allocation type is VXLAN, the shell also creates the VXLAN-to-VLAN VNI mapping on the auto-discovered VTEP.

References

To download and share integrations, see Quali Community's Integrations.

For instructional training and documentation, see Quali University.

To suggest an idea for the product, see Quali's Idea box.

To connect with Quali users and experts from around the world, ask questions and discuss issues, see Quali's Community forums.

Release Notes

Sonic Switch 2G Shell

For release updates, see the shell's GitHub releases page.

This shell is licensed under the Apache License 2.0.