Release date: June 2018
Shell version: 2.0.0
Document version: 1.0
- Overview
- Downloading the Shell
- Importing and Configuring the Shell
- Updating Python Dependencies for Shells
- Typical Workflows
- References
- Release Notes
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.
CloudShell's networking shells provide L2 or L3 connectivity between resources.
The Arista EOS Router 2G shell provides you with connectivity and management capabilities such as device structure discovery and power management for the Arista EOS Router.
For more information on the Arista EOS Router, see the official Arista product documentation.
Arista EOS Router 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.
Release: Arista EOS Router 2G Shell version 1.0.0
▪ CloudShell version: 8.0 and above
Note: If your CloudShell version does not support this shell, you should consider upgrading to a later version of CloudShell or contact customer support.
The shell's data model includes all shell metadata, families, and attributes.
The router families and models are listed in the following table:
| Family | Model | Description |
|---|---|---|
| CS_Router | Arista EOS Router 2G | Generic Arista EOS router 2G |
| CS_Chassis | Generic Chassis | Default router 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 |
Note: Attributes noted with an * also appear in the Discover resource dialog box (Inventory>Resource>Discover).
The attribute names and types are listed in the following table:
| Attribute | Type | Default value | Description |
|---|---|---|---|
| Name | String | Name of the Arista EOS Router in CloudShell. | |
| Address* | String | IP address of the Arista EOS Router. | |
| Folder | String | Root | CloudShell folder in which to place the resource. |
| Visibility | Lookup | Family Default (Everyone) | Visibility determines who can see the resource in the diagram, search pane, and in the Inventory dashboard. By default, visibility is defined in the resource family and can be changed for a specific resource. Possible values: Family Default (Everyone), Admin only, and Everyone. |
| Remote Connection | Lookup | Family Default (Enable) | Remote connection determines if you can remotely connect to the resource. By default, remote connection is defined in the resource family and can be changed for a specific resource. Possible values: Family Default (Enable), Enable, and Disable. |
| User* | String | Username for Arista CLI (should be privileged user). | |
| Password* | Password | Password for Arista CLI. | |
| Enable Password* | Password | Enable Password for Arista CLI. | |
| Sessions Concurrency Limit* | Numeric | 1 | Maximum number of concurrent sessions that the driver can open to the device. Defines the number of commands that can run concurrently. Default value of 1 = no concurrency. |
| System Name | String | A unique identifier for the device, if it exists in the device terminal/OS. | |
| Contact Name | String | Name of contact registered in the device. | |
| OS Version | String | Operating system version. | |
| Vendor | String | Name of device manufacturer. | |
| Location | String | Identifier of the device's physical location, for example, Lab1/Floor2/Row5/Slot4. | |
| Model | String | The device model. This information is typically used for abstract resource filtering. | |
| Model Name | String | The catalog name of the device model. This attribute will be displayed in CloudShell instead of the CloudShell model. | |
| Enable SNMP* | Boolean | True | If set to True, and SNMP isn’t enabled on the device, the shell will automatically enable SNMP on the device when the Autoload command is called, using the SNMP Write or Read Community value. If the value is empty, this will result in an error. SNMP must be enabled on the device for the Autoload command to run successfully. |
| Disable SNMP* | Boolean | False | If set to True, the shell will automatically disable SNMP after the Autoload command execution is completed. |
| SNMP Read Community* | Password | SNMP Read Community string functions like a password. It is sent along with each SNMP Get Request and allows (or denies) access to the device, for the Autoload functionality to run successfully. | |
| SNMP Write Community* | Password | SNMP Write Community functions like a password. It is sent along with each SNMP Set Request and allows (or denies) changing MIB values. | |
| SNMP V3 User | String | SNMP version 3 user name, relevant only if SNMP v3 is in use. | |
| SNMP V3 Password | Password | SNMP version 3 password, relevant only if SNMP v3 is in use. | |
| SNMP V3 Private Key | String | SNMP version 3 private key, relevant only if SNMP v3 is in use. | |
| SNMP V3 Authentication Protocol | Lookup | No Authentication Protocol | Relevant only if SNMP v3 is in use. Possible values: No Authentication Protocol, MD5, and SHA. |
| SNMP V3 Privacy Protocol | Lookup | No Privacy Protocol | Relevant only if SNMP v3 is in use. Possible values: No Privacy Protocol, DES, 3DES-EDE, AES-128, AES-192, and AES-256. |
| SNMP Version* | String | v2c | Specifies the SNMP version, Autoload will use to load attributes. Possible values: v1, v2c, and v3. |
| Console Server IP Address* | String | IP Address of console server in IPv4 format. Shell allows you to connect to the device through the console server. | |
| Console User* | String | User name for the console server. | |
| Console Password* | Password | Password for the console server. | |
| Console Port* | Numeric | Port for the console server, usually the TCP port, which the device is associated with. | |
| CLI Connection Type* | Lookup | Auto | Protocol which the shell will use to connect to the device. Possible values: Auto, Console, SSH, Telnet, and TCP. If Auto is selected, the driver will automatically choose the available connection type. |
| CLI TCP Port* | Numeric | TCP Port to use for CLI connection. If empty, a default CLI port will be used based on the chosen protocol, for example Telnet will use port 23. | |
| Power Management* | Boolean | False | Used by the power management service, if enabled to determine whether to automatically manage the device power status. |
| Backup Type* | String | File System | Supported protocols for saving and restoring configuration and firmware files. Possible values: File System, FTP and TFTP. |
| Backup Location* | String | Used by the Save and Restore orchestration scripts to determine where backups should be saved. | |
| Backup User* | String | Username for the storage server used for saving and restoring configuration and firmware files. | |
| Backup Password* | Password | Password for the storage server used for saving and restoring configuration and firmware files. | |
| VRF Management Name* | String | Default VRF Management name, if configured in the network and there was no input passed in the Save, Restore or Load Firmware commands. | |
| Model | String | Element model (Module or Chassis, etc.) | |
| Serial Number | String | Element serial number (Module or Chassis, etc.) | |
| Model Name | String | Element model name (Module or Chassis, etc.) | |
| Version | String | Element version (Module or Chassis, etc.) | |
| Mac Address | String | Interface Mac address | |
| L2 Protocol Type | String | Interface protocol type | |
| IPv4 Address | String | Interface IPv4 address | |
| IPv6 Address | String | Interface IPv6 address | |
| Port Description | String | Interface description | |
| Bandwidth | Numeric | 0 | Interface speed |
| MTU | Numeric | 0 | Interface MTU |
| Duplex | Lookup | Half | Interface duplex. Possible values: Half, or Full. |
| Adjacent | String | If LLDP is enabled on the port, Adjacent shows connected device name and interface. | |
| Protocol Type | Lookup | Transparent | Attribute for internal usage. |
| Auto Negotiation | Boolean | False | Shows if Auto Negotiation is enabled on the interface. |
| Association | String | Interfaces added to certain port-channels. |
This section describes the automation (driver) 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.
| Command | Description |
|---|---|
| Autoload | Discovers the chassis, its hierarchy and attributes when creating the resource. The command can be rerun in the Inventory dashboard and not in the sandbox, as for other commands. |
| Health Check | Checks if the device is powered-up and connectable. |
| Send Custom Command | Executes a custom command on the device. All commands can be executed in Enable mode, except for configuration. Set the command input as follows: ▪ Command: The command to run. Note that commands requiring a response are not supported. |
| Run Custom Config Command | Sends command to the device in Configuration mode and prints the output. All commands will be executed in the Enable mode and are accessible only via the API. |
| Save | Creates a configuration file and saves it to the provided destination. Set the command inputs as follows: ▪ Folder Path (String): Path where the configuration file will be saved. It should be accessible from the execution server. The path should include the protocol type, for example: tftp://asdf. ▪ Configuration Type (Enum): Specify whether the file should update the Startup or Running config. - Startup: Configuration that is loaded when the device boots or powers up. - Running: Current configuration in the device. It may have been modified since the last boot. ▪ VRF Management Name (String): (Optional) Virtual routing and forwarding management name. |
| Restore | Restores a configuration file from the saved file. Set the command inputs as follows: ▪ Path (String): The full path from which the configuration file will be restored. The path should include the protocol type, for example: tftp://asdf. ▪ Configuration Type (Enum): Specify whether the file should update the Startup or Running config. - Startup: Configuration that is loaded when the device boots or powers up. - Running: Current configuration in the device. It may have been modified since the last boot. ▪ Restore Method (Enum): Determines whether the restore should append or override the current configuration. ▪ VRF Management Name (String): (Optional) Virtual routing and forwarding management name. |
| Load Firmware | Uploads and updates the firmware on the resource. Set the command inputs as follows: ▪ Path (String): Path to tftp://server where the firmware file is stored. ▪ VRF Management Name (String): (Optional) Virtual routing and forwarding management name. |
The Arista EOS Router 2G shell is available from the Quali Community Integrations page.
Download the files into a temporary location on your local machine.
The shell comprises:
| File name | Description |
|---|---|
| AristaEosRouterShell2G.zip | Arista EOS Router 2G shell package |
| cloudshell-networking-arista-eos-router-shell-2g-dependencies-package-1.0.X.zip | Shell Python dependencies (for offline deployments only) |
This section describes how to import the Arista EOS Router 2G shell and configure and modify the shell’s devices.
To import the shell into CloudShell:
-
Make sure you have the shell’s zip package. If not, download the shell from the Quali Community's Integrations page.
-
In CloudShell Portal, as Global administrator, open the Manage – Shells page.
-
Click Import.
-
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.
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.
-
For CloudShell version 8.2, perform the appropriate procedure: Adding Shell and script packages to the local PyPi Server repository or Setting the python pythonOfflineRepositoryPath configuration key.
-
For CloudShell versions prior to 8.2, see Setting the python pythonOfflineRepositoryPath configuration key.
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:
-
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).
-
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. -
In the Quali Community's Integrations page, locate the shell and click the shell's Download link. In the page that is displayed, from the Downloads area, extract the dependencies package zip file.
-
-
Place these zip files in the local PyPi Server repository.
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:
-
Download the cloudshell-networking-arista-eos-router-shell-2g-dependencies-package-1.0.X.zip file, see Downloading the Shell.
-
Unzip it to a local repository. Make sure the execution server has access to this folder.
-
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"/> -
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"/> -
Restart the Execution Server.
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:
-
In the CloudShell Portal, in the Inventory dashboard, click Add New.
-
From the list, select AristaEosRouterShell2G.
-
Enter the Name and IP address of the Arista EOS Router.
-
Click Create.
-
In the Resource dialog box, enter the device's settings, see Arista EOS Router 2G Shell Attributes.
-
Click Continue.
CloudShell validates the device’s settings and updates the new resource with the device’s structure.
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.
To update offline Python dependencies:
-
Download the latest Python dependencies package zip file locally.
-
Extract the zip file to the suitable offline package folder(s).
-
Restart any execution server that has a live instance of the relevant driver or script. This requires running the Execution Server's configuration wizard, as explained in the Configure the Execution Server topic of the CloudShell Suite Installation guide.
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, restart the execution server, as explained above. 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.
-
In CloudShell Portal, add the Arista EOS resource to your blueprint and reserve the blueprint.
-
Run the Save resource command.
-
In the command inputs field, enter the following information:
- Folder Path: For example, tftp://ipaddress/shared folder.
- Configuration Type: Possible values are Startup or Running.
- VRF Management Name: Provide the VRF Management name, if relevant.
-
Click Run.
The Startup or Running configuration is saved to a file named -<startup/running-config>-, which will be stored in the folder path you entered above.
-
In CloudShell Portal, add the Arista EOS resource to your blueprint and reserve the blueprint.
-
Run the Restore resource command.
-
In the command inputs field, enter the following information:
- Path: (Mandatory) Enter the full path of the configuration file.
- Restore Method: (Optional) Possible values are Override or Append. If left empty, the Override method will be used.
- Configuration Type: (Mandatory) Possible values are Startup or Running.
- VRF Management Name: (Optional) Provide the VRF Management name, if relevant.
-
Click Run.
-
In CloudShell Portal, add the Arista EOS resource to your blueprint and reserve the blueprint.
-
Run the Load Firmware resource command.
-
In the command inputs field, enter the following information:
- Path (mandatory input field). Enter the full path to the firmware file on the remote host, for example: tftp://10.1.1.1/both.tim.
-
Click Run.
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.
Arista EOS Router 2G version 1.0.0
- Shell does not support configuring SNMP v3