cloud Deployment
Using cloudEOS router on the AWS Platform
The cloudEOS router, built on the Arista EOS and operating as a virtual machine instance on AWS EC2, enables the creation of diverse virtual machine router instances, including gateway and transit routers, for AWS deployment.
cloudEOS router Image Updates
The process to update cloudEOS router images is the standard update process used for EOS images.
For details on the steps, refer to the Arista EOS User Manual (see https://www.arista.com/en/support/product-documentation).
Amazon Machine Image (AMI) Specifications
The AMI provided by Arista utilizes the architecture, type of root device, virtualization type, and interface type required to configure the cloudEOS router for a robust AWS deployment.
- Architecture: x86_64
- Virtualization type: HVM
- Root Device Type: EBS
- Network Interface type: SR-IOV, ENA (Elastic Network Adapter)
- Supported Region: All AWS regions except China and Osaka. Consult the official listing for all AWS regions here: https://aws.amazon.com/about-aws/global-infrastructure/regions_az/.
Methods for Launching cloudEOS router Instances
The cloudEOS router supports various methods for launching router instances needed in a typical AWS deployment.
Launching cloudEOS router Instances Using AWS cloudFormation
Creating a cloudFormation stack to launch the instance is how you use AWS cloudFormation to launch cloudEOS router instances. The stack provides the base configuration for the instance. Select a stack template that defines this base configuration as part of this task.
Select the stack template that provides the resources required for the launching instances. Templates can be obtained from https://github.com/aristanetworks. For more information about AWS cloudFormation stacks and using stack templates, refer to the AWS documentation (see https://aws.amazon.com/documentation/cloudformation/).
- Log in to the Amazon Management Console.
- Choose Services > cloudFormation.
The cloudFormation page will appear, showing the current stacks available for use.

- Click the Create Stack button.
The page refreshes, showing the options for specifying the details for the stack.

- Select a nic template for upload, and then click the Next button.
Note: Templates can be found in the docs directory. Press Select to choose the desired AMI.
The page refreshes, showing the options for specifying the details for the stack.

- Enter the Stack Name, Subnet IP Block for each interface, VPC ID, KeyPair Name, UserData in base64 format, and AMI ID. (To convert UserData from text to base64 format, use a base64 command on MacOS or Linux machine.)
# base64 %EOS-STARTUP-CONFIG-START% hostname myhost %EOS-STARTUP-CONFIG-END% <Press CTRL+D> JUVPUy1TVEFSVFVQLUNPTkZJRy1TVEFSVCUKaG9zdG5hbWUgbXlob3N0CiVFT1MtU 1RBUlRVUC1DT05GSUctRU5EJQo= - Review the details and make changes if needed.
- Click the Create button to create the stack.

- Wait for the stack creation to complete. Resources created as part of the stack creation process can be viewed in the Resource tab.

- Click the cloudEOS router Instance ID to view the status of the cloudEOS router instance. The Instance ID is shown in the Physical ID column of the Resources tab.

-
Recommended Usage
When an EC2 instance with multiple network interfaces is launched or started from a stopped state, AWS cannot automatically assign a public IPv4 address. If this occurs, the user can only connect to the instance over IPv4 by assigning an Elastic IP address to the primary network interface (eth0). If the user prefers not to associate an Elastic IP address with the cloudEOS router instance, it is recommended to attach any additional interfaces only when the instance is running. Once additional interfaces are attached, the user should avoid stopping and starting the instance. Instead of stopping and starting the instance, the user can reboot it from the AWS console or within the cloudEOS router using the CLI or bash commands. This is because rebooting the instance does not cause the public IPv4 address to be released, while stopping the instance does.For instructions on how to associate an Elastic IP address to your instance or primary network interface, please refer to https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html.
Launching cloudEOS router Instances Using EC2 AWS Marketplace
Available Options
- Assigning an IAM role to the instance
To enable AWS services on the instance (AWS cloudWatch logs), assign an IAM role to the instance during this procedure. Assign an IAM role to the instance by:
- Selecting an existing IAM role.
- Creating a new IAM role (an option is provided as part of the procedure to create a new IAM role).
Refer to the following AWS documentation for details about creating EC2 key pairs and creating IAM roles.
- Creating EC2 key pairs (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html).
- Creating an IAM role (https://docs.aws.amazon.com/AmazoncloudWatch/latest/logs/QuickStartEC2Instance.html).
- Using instance user data to configure the instance
cloudEOS router supports using cloudEOS router instance user data to configure cloudEOS router instances at launch. This involves uploading instance user data to the instance through the Advanced Details dialog. The options are copying and pasting a configuration into the dialog or attaching a configuration file.
For details on composing user data for cloudEOS router, see Using User-data for Configuration of Entities and cloudEOS router Instances.
- Log in to the Amazon Management Console.
- Create an EC2 key pair and download the .pem file that contains the private key. (The .pem file may download automatically.)
To create an EC2 pair, go to https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html.

- Go to the EC2 Dashboard.
- From the EC2 Dashboard, click Instances in the left pane.
The Launch Instance page appears.

- Click the Launch Instance button.
The page appears for you to select an AMI.

- Click AWS Marketplace in the left pane.
Search for Arista cloudEOS router in the search field to bring up the available cloudEOS router AMIs. Select the appropriate AMI for launching.

- A screen shows the user highlights, pricing details, and available instance types. Press the Continue button to advance.

- Click the left pane.
Choose an Instance Type page appears.

Select an instance type that meets the requirements for the cloudEOS router instance.
- Click the Next: Configure Instance Details button (lower right part of the page).
The Configure Instance Details page appears.

- (Optional) Create a new IAM role or select an existing IAM role. (This is required to enable AWS services on the instance, for example, AWS cloudWatch logs.)
- (Optional) To configure advanced details for the instance, scroll down to the bottom of the page and click the Advanced Details button.
The Advanced Details dialog appears. You use the dialog to upload user data and configure the instance.
Do one of the following to configure the instance using user data:- Choose the Text option, then copy and paste startup-config in the text box.
- Attach the configuration as a file by clicking on the file and then choosing the configuration file to upload.
For details on composing user data for cloudEOS router, see Using User-data for Configuration of Entities and cloudEOS router Instances.
- From the Configure Instance Details page, click the Review and Launch button.
The Review Instance Launch page appears.

- Click the Launch button.
A dialog appears when selecting a key pair.

- Select the key pair created earlier in the procedure using the Select a key pair menu. In this example, the key pair is named "systest."
Select the acknowledgment (near the bottom of the dialog), then click the Launch Instances button.
The Launch Status page appears, showing the status of the instance. The deployment takes a few minutes to complete.

- Click the blue link to the instance to view details about the instance. (The link is in the "Your instances are now launching" box near the top of the page.)
The page shows the details for the instance.

- Make sure the Instance State shows running. Wait for the status to update to running.
- (Optional) To use the existing subnet and security group for the instance, record the subnet and security group. This information is required when configuring the network interfaces to be attached to the instance.
- (Optional) Click the Connect button near the top of the page.
The Connect to Your Instance dialog appears.

- Connect to the instance using the public or private IP address. The correct syntax is:
ssh -i <privateKey.pem> This email address is being protected from spambots. You need JavaScript enabled to view it..#ssh -i <privateKey.pem> This email address is being protected from spambots. You need JavaScript enabled to view it.Complete the networking tasks for the cloudEOS router instances in the gateway topology (see Network Configuration Tasks for cloudEOS router Instances).
Configuring the AWS cloudWatch Logs Agent
The AWS cloudWatch Logs Agent is the mechanism that publishes cloudEOS router logs to AWS cloudWatch. Configuring the AWS cloudWatch Logs Agent ensures that the cloudEOS router logs published to AWS cloudWatch conform to the selected requirements. The AWS cloudWatch Logs Agent is packaged with the awslogs.swix cloudEOS router extension, is installed and enabled by default when the cloudEOS router instances launch through the AWS Marketplace.
Refer to the “AWS cloudWatch Quick Start Guide” to make sure that the cloudEOS router instance has the right credentials for logging in to AWS.
The location where cloudEOS router logs are published depends on the AWS cloudWatch Logs configuration. By default, the logs are located under cloudWatch, "log group, name cloudEOS routerlogs.
- Editing configuration files under the /mnt/flash/awslogs/ directory.
- Passing instance user-data. Make sure to use the correct start and end markers, which are:
%AWSLOGS-CONFIG-START% #configuration here %AWSLOGS-CONFIG-END% %AWS-PROXY-START% #configuration here %AWS-PROXY-END%Note: Restart awslogs using sudo systemctl restart awslogs under bash. The reconfiguration only takes effect after awslogs restarts.
cloudEOS router log filenames
By default, the hostname of the cloudEOS router instance is the filename of all cloudEOS router logs for that instance.
Network Configuration Tasks for cloudEOS router Instances
Complete additional configuration tasks to ensure that the cloudEOS router instances launched have the required networking configuration. The configuration tasks include:
- Creating the additional network interfaces required by the topology.
- Attaching the new interfaces to cloudEOS router instances.
- Configuring the route table of the AWS Specific cloud router.
Creating the Additional Network Interfaces
Creating the additional network interfaces required for the topology ensures that interfaces can be attached to cloudEOS router instances. When creating the new network interfaces, there is the option of using the subnet and security groups automatically assigned to the instance or specifying a different subnet and security groups for the instance.
Pre-requisites:
- Subnet ID
- Names of the security groups
Procedure
Complete these steps to create network interfaces.
Attach the new network interface to a cloudEOS router instance (see Attaching the New Network Interfaces to Instances).
Attaching the New Network Interfaces to Instances
Attaching the new network interfaces to cloudEOS router instances is the second networking configuration task. This task involves selecting the new network interfaces created in the previous procedure and then attaching the interfaces to cloudEOS router instances.
Complete these steps to attach the new network interfaces to cloudEOS router instances.
Configure the route table of the AWS router (see Configuring the Route Table of the AWS router).
Configuring the Route Table of the AWS router
To take advantage of the advanced services provided by cloudEOS router, configure the route table of the AWS router so that traffic is forwarded from the AWS router to cloudEOS router instances. This task involves logging into the AWS router and modifying route table entries for the cloudEOS router instances in which you want traffic forwarded.
Configure the AWS cloudWatch Logs Agent (see Configuring the AWS cloudWatch Logs Agent). Configuring the Agent ensures that the cloudEOS router logs are published to AWS.
cloudEOS router Startup-Configuration using Instance Custom-Data
Through user data, cloudEOS router supports startup configuration, AWS cloudWatch, and cloud HA. Because user-data can pass in configurations, administrators can use this feature to quickly configure cloudEOS router instances, AWS cloudWatch, and cloud HA.
- The configuration must be separated by start and end markers.
- Markers are required at the beginning of the line.
- You must upload either text or configuration files (these are the types of files supported by cloudEOS router).
EOS configuration for all interfaces can be passed on during deployment. The configuration takes effect as new interfaces attach to the cloudEOS router.
| Entity / Configuration File / Use | Markers | File Path |
|---|---|---|
| Entity: EOS
File: EOS CLI configuration file Use: Configure cloudEOS router |
%EOS-STARTUP-CONFIG-START%
%EOS-STARTUP-CONFIG-END% |
N/A |
| Entity: EOS
File: EOS CLI configuration file Use: %FORCE_USER_DATA% will forcibly apply the Arista startup configs in the user custom data under the %EOS-STARTUP-CONFIG-START% and %EOS-STARTUP-CONFIG-END% ) even when it is not a first time boot of the instance. |
%FORCE-USER-DATA% |
N/A |
| Entity: AWS Logs
File: aws.conf Use: Set up AWS region |
%AWS-CONFIG-START%
%AWS-CONFIG-END% |
/mnt/flash/awslogs/aws.conf |
| Entity: AWS Logs
File: awslogs.conf Use: Configure logging parameters |
%AWSLOGS-CONFIG-START%
%AWSLOGS-CONFIG-END% |
/mnt/flash/awslogs/awsconf.conf |
| Entity: AWS Logs
File: proxy.conf Use: Configure proxy settings |
%AWS-PROXY-START%
%AWS-PROXY-END% |
/mnt/flash/awslogs/proxy.conf |
Sample Instance User-data
The following sample user data contains lines to start the instance and to configure various entities.
- AWS cloudWatch logs (for the us-east-1 region)
- AWS logging parameters
- AWS proxy settings
Sample
%EOS-STARTUP-CONFIG-START%
! EOS startup config
hostname my-veos
username admin nopassword
username admin sshkey file flash:key.pub
%EOS-STARTUP-CONFIG-END%
%AWS-CONFIG-START%
[plugins]
cwlogs = cwlogs
[default]
region = us-east-1
%AWS-CONFIG-END%
%AWSLOGS-CONFIG-START%
[general]
state_file = /var/awslogs/state/agent-state
[/var/log/messages]
datetime_format = %b %d %H:%M:%S
file = /var/log/messages
buffer_duration = 5000
log_group_name = veoslogs
log_stream_name = {hostname}
initial_position = start_of_file
%AWSLOGS-CONFIG-END%
%AWS-PROXY-START%
HTTP_PROXY=http://<your_proxy>:<your_proxy_port>
HTTPS_PROXY=http://<your_proxy>:<your_proxy_port>
NO_PROXY=169.254.169.254
%AWS-PROXY-END%
Using the cloudEOS router on Microsoft Azure
cloudEOS router Image Updates
The process you use to update cloudEOS router images is the standard update process used for EOS images.
For details on the steps, refer to the Arista EOS User Manual (seehttps://www.arista.com/en/support/product-documentation).
Launching a cloudEOS router Azure Instance
Two methods can be used to launch a cloudEOS router instance.
- Portal Marketplace This method launches an instance using the Azure Portal Marketplace UI.
Note: Arista recommends using only the v2 instance type for better pricing and performance while creating an instance using Azure Marketplace. Also, it enables Accelerated Networking on all the interfaces while creating an instance.
- Azure CLI 2.0: This method launches an instance using a custom template through the Azure CLI 2.0. The primary advantage of a CLI deployment is the ability to include custom data and customize your deployment.
Creating an Instance using the Portal Marketplace
Complete the following steps to create an instance using the Portal Marketplace.
Creating an Instance under Azure CLI 2.0
Complete the following steps to create an instance under Azure CLI 2.0.
Logging into Instance
To log into an instance, complete the following steps.
cloudEOS router Startup-Configuration using Instance Custom-Data
Describes launch employing custom-data information.
Azure provided a feature to upload custom data during the initial launch of the router Instance. The administrator can upload the router configuration using custom-data when the router Instance is launched.
Custom data can be used to pass in configuration for multiple entities. Currently, only the EOS configuration is supported in Azure. This configuration must be separated by start and end markers.
|
Entity |
Markers |
File Path |
|---|---|---|
| EOS CLI configuration file |
|
N/A |
|
EOS CLI configuration file Use: %FORCE_USER_DATA% will forcibly apply the Arista startup configs in the user custom data under the %EOS-STARTUP-CONFIG-START% and %EOS-STARTUP-CONFIG-END% ) even when it is not a first-time boot of the instance. |
%FORCE_USER_DATA% |
N/A |
- Markers must be at the beginning of the line.
- The user is expected to have tested the configurations on a live system before using the configurations to deploy the new router. Mis-configuration may result in an unrecoverable instance.
- EOS configuration for all interfaces can be passed on during deployment. The configuration takes effect as the new instances attach to the router.
Sample Instance Custom-Data
The following illustrates a sample Instance with custom-data.
%EOS-STARTUP-CONFIG-START%
! EOS startup config
username admin nopassword
username admin sshkey file flash:key.pub
%EOS-STARTUP-CONFIG-END%
Providing Startup-Configuration using Azure Custom-Data
Adding custom-data to an instance.
Currently, custom-data can only be used on instances deployed using the Azure CLI 2.0.
To add custom-data to an instance, the custom-data must be provided as a single-line value with '\n' delimiting newlines.
Use the single_line_json.sh script to convert your custom-data into this format.
#!/usr/bin/bash
cat $1 | python -c 'import json, sys; print( json.dumps( sys.stdin.read() ) )'
The usage of the script is as follows:
./single_line_json.sh user_data.txt
Copy and paste the generated output into the customData value field of the JSON parameters file.
Troubleshooting Instance
To troubleshoot the instance, complete the following steps.
Resources
Additional resources.
- How To Deploy Resources - https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-template-deploy-cli
Arista cloudEOS router On Google cloud Platform (GCP)
Arista cloudEOS routeris now supported on Google cloud Platform (GCP) and other public and private clouds.
Overview
Arista cloudEOS router
Arista cloudEOS router, a cloud-grade and feature-rich virtual router for Google cloud, is now available as a software subscription in Google cloud Launcher. This software-only release of EOS software supports public clouds and customer premises equipment running Linux and VMware hypervisors. cloudEOS router provides a consistent, secure, and universal approach to hybrid cloud networking for any virtualized cloud deployment by offering advanced network telemetry and secure IPSec VPN connectivity in a software-only package.
The BYOL and PAYG license models are both available. A cloudEOS router license activation key must be obtained separately from Arista for the BYOL instance to unlock the platform from a default performance limit of 10 Mbps and enable IPsec encrypted VPNs. The PAYG instance automatically installs the license, allowing customers to use all features, including IPsec and uncapped throughput. For more information about licensing, refer to License Management.
Deploying Arista cloudEOS on GCP
Logging into Arista cloudEOS
cloudEOS router Startup-Configuration using Instance Custom-Data
This section discusses the use of custom-data during the initial deployment of the router instance, GCP provides an option to upload custom-data. The custom-data used passes in the configuration for multiple entities. Currently, GCP supports only the EOS configuration. This configuration is separated using start and end markers.
The administrator can upload router configuration using custom-data while launching a router instance through the portal, as shown below. Note that the custom-data works only during the first boot.
- Markers must be at the beginning of the line.
- The user is expected to have tested the configurations on a live system before using the configurations to deploy the new router. Mis-configuration may result in an unrecoverable instance.
- EOS configuration for all interfaces is passed on during the deployment. The configuration takes effect as the new instances attach to the router.
|
Entity |
Markers |
File Path |
|---|---|---|
| EOS CLI configuration file |
|
N/A |
|
EOS CLI configuration file Use: %FORCE_USER_DATA% will forcibly apply the Arista startup configs in the user custom data under the %EOS-STARTUP-CONFIG-START% and %EOS-STARTUP-CONFIG-END% ) even when it is not a first time boot of the instance. |
%FORCE_USER_DATA% |
N/A |
Configuring custome-data for GCP instance through portal.

Using the cloudEOS router on KVM and ESXi
This section discusses the system requirements, installation, and configuration procedures for the cloudEOS router on the hypervisor.
Server
A server can be either a hardware or software entity.
A hardware server is a physical computer that executes the virtual machine manager or hypervisor and all the virtual machines, also known as the host machine.
A software server is the hypervisor or virtual machine manager that hosts and manages the virtual machines. It is also sometimes referred to as the host.
VMware ESXi Minimum Server Requirements
- Ethernet NICs must be SR-IOV capable
- BIOS / System Firmware support for SR-IOV
- 8 GB free disk space
- 16 GB RAM
- 4 cores running a minimum 2.4GHz or greater and 16 GB memory
- Intel VT-x and VT-d support
- Ethernet NICs must be SR-IOV capable
- BIOS / System Firmware support for SR-IOV
KVM Requirements
cloudEOS router must be deployed on an x86-64 architecture server running a KVM hypervisor.
- 8 GB free disk space
- 16 GB RAM
- x86-64 Server class CPU (32-bit CPUs are not supported) with
- Intel VT-x or AMD-V support for CPU Virtualization
- Intel VT-d or AMD-IOMMU support for PCIe passthrough
- Intel AES-NI support
- 4 CPU cores running at 2.4GHz.
- Ethernet NICs must be SR-IOV capable
- BIOS / System Firmware support for SR-IOV
Supported Topologies
- Launching ESXi using vSphere Web Client
- Launching cloudEOS router on KVM with Linux bridge
- Launching cloudEOS router on KVM with SR-IOV
- Launching cloudEOS router on KVM with PCI-Passthrough
VMware ESXi Hypervisor
This section discusses the launch sequence for VMware ESXi 6.0 and 6.5.
Launching VMware ESXi 6.0 and 6.5
Launching VMWare ESXi 6 and ESXi 6.5 for WAN.
There are different ESXi user interfaces for managing the ESXi host, such as the vSphere Web Client and the ESXi Web Client. The following task is required to launch VMware 6.0 and 6.5 and provides a general guideline on the steps involved in deploying virtual machines with an OVF/OVA template.
- From the vCenter Server WEB-UI navigator, select Deploy OVF template.

- Select the OVA file from the local machine.

- Select the name and location for WAN deployment.

- Select the host, cluster, resource pool, or VAPP.

- Verify the template details.

- Select Thick provision eager zeroed from the datastore.

- Select the default network.

- Complete the launch process.

- The deployment progress will be displayed under the Recent Tasks tab at the bottom of the page after the deployment is complete, power-on the machine.

Enabling SR-IOV or PCI Passthrough on ESXi
Describes how to enable single route input/output vitalization (SR-IOV) or PCI passthrough on VMware ESXi.
To enable SR-IOV or PCI passthrough on ESXi, complete the following steps.
KVM
This section discusses the system requirements, installation and configuration procedures for cloudEOS router.
Server
A hardware server is the physical computer that executes the virtual machine manager or hypervisor and all the virtual machines. This is also known as the host machine.
A software server is the hypervisor or virtual machine manager that hosts and manages the virtual machines. It is also sometimes referred to as the host. In this document, the software server comprises RedHat Linux with virtualization support (KVM).
System Requirements
Below are the minimum system requirements for using KVM.
Minimum Server Requirements
Any VMware supported ESXi server hardware.
- RedHat 7x with virtualization support. Please see below for virtualization https://wiki.centos.org/HowTos/KVM.
- Libvirt is installed by executing virsh list which should return without errors. Python 2.7+ is required to run the installation script vSphere 6.0.
veos Virtual Machine
- 2 vCPUs
- 4GB Memory
- 8G Free disk space
- 16 vCPUs
- 8 network interfaces
Supported Images
| Image Name | File Name | Details |
|---|---|---|
| KVM veos image | EOS.qcow2 | Image Hard Disk that contains veos. This file can grow as agents in veos generates logs/traces, etc. |
Using Libvirt to Manage cloudEOS router VM on KVM
Libvirt is an open source library that provides cloudEOS router management for virtual machines.
Libvirt supports many functions, such as creating, updating, and deleting VMs.
The complete Libvirt command reference can be found at http://libvirt.org/virshcmdref.html.
Define a new VM
Define a domain from an XML file using the virsh define <vm-definition-file.xml > command. This defines the domain, but it does not start the domain.
The definition file has vm-name, CPU, memory, network connectivity, and a path to the image. The parameters are found at https://libvirt.org/formatdomain.html. A sample cloudEOS router file is included in the example below.
Undefine the Inactive Domain
Undefine the configuration for the inactive domain by using the virsh undefine <vm-name> and specifying its domain name.
Start VM
Start a previously defined or inactive domain using the virsh start <vm-name> command.
Stop VM
Terminate a domain immediately by using the virsh destroy <vm-name> command.
Managing Networks
- The virsh net-define <network-definition-file.xml> command.
- The virsh net-undefine network-name command removes an inactive virtual network from the libvirt configuration.
- The virsh start network-name command manually starts a virtual network that is not running.
- The virsh destroy network-name command shuts down a running virtual network.
Launching veos in LinuxBridge Mode
Use the script SetupLinuxBridge.pyc usage python SetupLinuxBridge.pyc <bridge- name>
- virsh define <veos define file say veos.xml>
- virsh start <veos-name>
- virsh console <veos-name>
<domain type='kvm'>
<!-- veos name, cpu and memory settings -->
<name>kvs1-veos1</name>
<memory unit='MiB'>4096</memory>
<currentMemory unit='MiB'>4096</currentMemory>
<vcpu placement='static'>2</vcpu>
<resource>
<partition>/machine</partition>
</resource>
<cpu mode='host-model'/>
<os>
<type arch='x86_64'>hvm</type>
<boot dev='cdrom'/>
<boot dev='hd'/>
</os>
<features>
<acpi/>
<apic/>
<pae/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>restart</on_crash>
<devices>
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='directsync'/>
<source file='/path_to_file/cloudEOS.qcow2'/>
<target dev='hda' bus='ide'/>
<alias name='ide0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>
<disk type='file' device='cdrom'>
<driver name='qemu' type='raw'/>
<source file='/path_to_file/Aboot-veos-serial.iso'/>
<target dev='hdc' bus='ide'/>
<readonly/>
<alias name='ide0-1-0'/>
<address type='drive' controller='0' bus='1' target='0' unit='0'/>
</disk>
<controller type='usb' index='0'>
<alias name='usb0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x2'/>
</controller>
<controller type='pci' index='0' model='pci-root'>
<alias name='pci0'/>
</controller>
<controller type='ide' index='0'>
<alias name='ide0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/>
</controller>
<!-- In this case management is connected to linux bridge -->
<interface type='bridge'>
<source bridge='brMgmt'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
</interface>
<serial type='pty'>
<source path='/dev/pts/4'/>
<target port='0'/>
<alias name='serial0'/>
<target port='0'/>
<alias name='serial0'/>
</serial>
<console type='pty' tty='/dev/pts/4'>
<source path='/dev/pts/4'/>
<target type='serial' port='0'/>
<alias name='serial0'/>
</console>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='5903' autoport='yes' listen='127.0.0.1'>
<listen type='address' address='127.0.0.1'/>
</graphics>
<video>
<model type='cirrus' vram='9216' heads='1'/>
<alias name='video0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</video>
<memballoon model='virtio'>
<alias name='balloon0'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</memballoon>
<!-- Has two data ports on different vlans
Cut and paste the more interface elements for more interfaces but increment the slot number.
Note that brWAN and brLAN bridges need to be created beforehand -->
<interface type='bridge'>
<source bridge='brWAN'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='5' function='0x0'/>
</interface>
<interface type='bridge'>
<source bridge='brLAN'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='6' function='0x0'/>
</interface>
</devices>
</domain>
Example Deployment
VIRTIO & Linux Bridging Deployment
veos can employ para-virtualized network I/O interfaces, which in Linux KVM is also known as Virtio. Each NIC is connected to a unique underlying Linux layer-2 bridge in the hypervisor, providing uplink access.
- Ethernet1 connects to the physical Ethernet port that connects to the cloudEOS router through a LinuxBridge. The router is configured with a cloudEOS router IP address on this port.
- Ethernet2 connects to the physical ethernet port that connects to the LAN through a LinuxBridge.
- The server IP address in the diagram is assumed to be configured on the LAN LinuxBridge device.
Setting Up the Host for Single Root I/O Virtualization (SR-IOV)
Single Root I/O Virtualization (SR-IOV) allows a single PCIe physical device under a single root port to appear to be multiple physical devices to the hypervisor.
- Verify the IOMMU Support.
Use the virt-host-validate Linux command to check the support of IOMMU (input/output memory management unit). If it does not "PASS" for IOMMU, check the BIOS and kernel settings.
The example below is what should be displayed.
[arista@solution]$ virt-host-validate QEMU: Checking for device assignment IOMMU support : PASS QEMU: Checking if IOMMU is enabled by kernel : PASS - Verify the Drivers are Supported.
Ensure the PCI device with SR-IOV capabilities is detected. An INTEL 82599 ES network interface card supporting SR-IOV is detected in the example below.
Verify the ports and NIC IDs in bold in the lspci | grep Ethernet Linux command output below.
# lspci | grep Ethernet 01:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 01:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 01:00.2 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 01:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 81:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 81:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 81:00.2 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 81:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 82:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 82:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 83:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 83:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) - Verify the driver kernel is active.
After confirming the device support, the driver kernel module should load automatically by the kernel. To verify the driver kernel is active, use the lsmod | grep igb Linux command.
[root@kvmsolution]# lsmod | grep igb igb 1973280 ptp192312 igb,ixgbe dca151302 igb,ixgbe i2c_algo_bit 134132 ast,igb i2c_core 407566 ast,drm,igb,i2c_i801,drm_kms_helper,i2c_algo_bit - Activate Virtual Functions (VFs).
The maximum number of supported virtual functions depends on the type of card. To activate the VFs, use [arista@localhost]$ /sys/class/net/<Device_Name>/device/sriov_numvfs or the method shown in the example below, it shows that the PF identifier 82:00.0 supports a total of 63 VFs.
Example
[arista@localhost]$ cat/sys/bus/pci/devices/0000\:82\:00.0/sriov_totalvfs 63To activate the seven VFs per PFs and make them persistent after reboot, add the line options igb max_vfs=7 in ixgbe.conf, and the sriov.conf files in /etc/modprobe.d
- Use the rmmod ixgbe and modprobe ixgbe Linux commands to unload and reload the module.
- Verify the VFs are detected.
Verify the VFs are detected using the lspci | grep Ethernet Linux command. For the two identifiers 82:00.0 and 82:00.1, 14 VFs are detected.
# lspci | grep Ethernet 82:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 82:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 82:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:10.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:10.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:10.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:10.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:11.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:11.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:11.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:11.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:11.4 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) 82:11.5 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01) - Locate the serial numbers for the PFs and VRFs
Locate the serial numbers for the PFs and VFs. The Linux virsh nodedev-list | grep 82 command below displays the serial number for identifiers 82:00.0 and 82:00.1. The first two numbers are the serial numbers for the PFs, and the remaining is the serial numbers for the VFs.
# virsh nodedev-list | grep 82 pci_0000_82_00_0 pci_0000_82_00_1 pci_0000_82_10_0 pci_0000_82_10_1 pci_0000_82_10_2 pci_0000_82_10_3 pci_0000_82_10_4 pci_0000_82_10_5 pci_0000_82_10_6 pci_0000_82_10_7 pci_0000_82_11_0 pci_0000_82_11_1 pci_0000_82_11_2 pci_0000_82_11_3 pci_0000_82_11_4 pci_0000_82_11_5 - Select the serial number of the VF.
Select the serial number of the VF that will attach to the VM (veos). Locate the bus, slot, and function parameters using the Linux virsh nodedev-dumpxml <serial number> command. For example, serial number pci_0000_82_11_1 displays the following details.
# virsh nodedev-dumpxmlpci_0000_82_11_1 <device> <name>pci_0000_82_11_1</name> <path>/sys/devices/pci0000:80/0000:80:02.0/0000:82:11.1</path> <parent>computer</parent> <driver> <name>ixgbevf</name> </driver> <capability type='pci'> <domain>0</domain> <bus>130</bus> <slot>17</slot> <function>1</function> <product id='0x10ed'>82599 Ethernet Controller Virtual Function</product> <vendor id='0x8086'>Intel Corporation</vendor> <capability type='phys_function'> <address domain='0x0000' bus='0x82' slot='0x00' function='0x1'/> </capability> <iommuGroup number='71'> <address domain='0x0000' bus='0x82' slot='0x11' function='0x1'/> </iommuGroup> <numa node='1'/> <pci-express> <link validity='cap' port='0' width='0'/> <link validity='sta' width='0'/> </pci-express> </capability> </device> - Create a new Interface.
Shutdown the veos VM if it is already running. Open the XML file for the specific veos VM for editing using the Linux command virsh edit <vm-name>. In the interface section, create a new interface by adding the details as shown below. The bus, slot, and function values are in the hexadecimal format of the decimal values found in Step 7.
<interface type='hostdev' managed='yes'> <source> <address type='pci' domain='0x0000' bus='0x82' slot='0x11' function='0x1'/> </source> </interface> - Start the veos VM. Verify there is an added interface on the VM. Using the command ethtool -i et9 to verify that the driver for the added interface is ixgbevf.
switch(config)# show interface status Port NameStatus Vlan Duplex SpeedType Flags Et9 notconnect routed unconfunconf 10/100/1000 Ma1 connectedrouted a-fulla-1G 10/100/1000 [admin@veos]$ ethtool -i et9 driver: ixgbevf version: 2.12.1-k firmware-version: bus-info: 0000:00:0c.0 supports-statistics: yes supports-test: yes supports-eeprom-access: no supports-register-dump: yes supports-priv-flags: no
Launching SR-IOV
veos can also use PCIE SRI-OV I/O interfaces. Each SRI-OV NIC is passed-through to the VM such that network I/O does not hit the hypervisor.The hypervisor and multiple VMs can share the same NIC card in this model.
- higher Performance ~ 2x.
- Better latency and jitter characteristics.
- veos directly receives physical port state indications from the virtual device.
- Using SR-IOV, virtualize the NIC.
- The NICs have a built-in bridge to do basic bridging.
- Avoids software handling of the packets in the kernel.
Setting Up the Host and Launching PCI Pass-through
Set up a networking device to use PCI pass-through.
- Identify Available Physical Functions.
Similar to the SR-IOV, identify an available physical function (a NIC in this scenario) and its identifier. The lspci | grep Ethernet Linux command displays the available physical functions.
In this example, 82:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection is the physical function, and 82:00.0 is the device identification code.
# lspci | grep Ethernet 01:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 01:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 01:00.2 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 01:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 81:00.0 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 81:00.1 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 81:00.2 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 81:00.3 Ethernet controller: Intel Corporation I350 Gigabit Network Connection (rev 01) 82:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 82:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 83:00.0 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) 83:00.1 Ethernet controller: Intel Corporation 82599ES 10-Gigabit SFI/SFP+ Network Connection (rev 01) - Verify Available Physical Functions.
Verify the available physical functions by using the virsh Linux commands.
[arista@solution]$ virsh nodedev-list | grep 82_00_0 pci_0000_82_00_0 [arista@solution]$ virsh nodedev-dumpxml pci_0000_82_00_0 <device> <name>pci_0000_82_00_0</name> <path>/sys/devices/pci0000:80/0000:80:02.0/0000:82:00.0</path> <parent>pci_0000_80_02_0</parent> <driver> <name>vfio-pci</name> </driver> <capability type='pci'> <domain>0</domain> <bus>130</bus> <slot>0</slot> <function>0</function> <product id='0x10fb'>82599ES 10-Gigabit SFI/SFP+ Network Connection</product> <vendor id='0x8086'>Intel Corporation</vendor> <capability type='virt_functions' maxCount='64'/>In this example, the domain is 0 (Hex domain=0x0), the bus is 130 (Hex bus=0x82), the slot is 0 (Hex slot=0x0), and the function is 0 (Hex function=0x0).
With the domain, bus, slot, and function information, construct the device entry and add it to the VMs XML configuration.
<devices> ... <hostdev mode='subsystem' type='pci' managed='yes'> <source> <address domain='0x0000' bus='0x82' slot='0x00' function='0x0'/> </source> </hostdev> - Verify the NIC was detected by the VM.
When starting the VM (veos in this case), the VM should detect NIC.
router# bash Arista Networks EOS shell [admin@veos1 ~]$ lspci | grep Ethernet 00:03.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) 00:05.0 Ethernet controller: Red Hat, Inc Virtio network device [admin@veos ~]$ - Verify Driver Requirements.
If the NIC is supported by the veos and any other driver requirements are met, the corresponding ethernet interfaces are available to use on the veos. Use the show interface command to display the available veos Ethernet interfaces.
router# show interfacestatus Port Name Status Vlan Duplex SpeedType Flags Et1connectedrouted full10G10/100/1000 Ma1connectedrouted a-fulla-1G 10/100/1000 router#bash bash-4.3# ethtool -i et1 driver: ixgbe version: 4.2.1-k firmware-version: 0x18b30001 bus-info: 0000:00:03.0 supports-statistics: yes supports-test: yes supports-eeprom-access: yes supports-register-dump: yes supports-priv-flags: no
Example Deployment
veos can use passthrough I/O interfaces where the network I/O does not hit the hypervisor. In this model, the VM owns the entire network card, thus fully bypassing the hypervisor.
- SR-IOV has the following advantages over LinuxBridge higher Performance ~ 2x.
- Better latency and jitter characteristics.
- veos directly receives physical port state indications from the virtual device.
Figure 16. Linux PCI Passthrough-based Deployment
Using the cloudEOS router On Arista Appliance (DCA-200-veos)
Overview
The appliance, used to host virtual cloudEOS router machines, utilizes a KVM Hypervisor and possesses two 2x10G SFP+ NIC cards for data traffic and two 1G ports for management traffic.
The cloudEOS router VM instance is specified with resources—including CPU cores, memory, and interfaces—based on customer network deployment models and desired performance. The cloudEOS router launcher script, dca-200-
veos-setup-vm.py, is used to efficiently launch new cloudEOS router instances with appropriate resources and network interface setups.
Hardware
- Two sockets with 10 CPU cores each. The server is configured for optimal cloudEOS router performance. For example, Hyperthreading has been turned off.
- 64 GB memory.
- Two 2 x 10G SFP+ NIC cards for a total of 4 10G NIC ports for data traffic.
- 2 x 1G ports (eno1 and eno2) for management.
- 2 x 1G ports (eno3 and eno4) NOT used by cloudEOS router launcher scripts.
- iDRAC
Interfaces
The figure below shows all the interfaces on the appliance.

Management Interfaces
The above figure shows that the appliance has 4 physical 1G ports --- eno1/2/3/4. eno1 and eno2 are aggregated to a bonded interface device0 in 802.3ad mode. So, they need to be connected to one or more network devices supporting Link Aggregation Control Protocol (LACP). Bonded interface device0 is internally connected to a Linux bridge named devicebr. cloudEOS router launcher script will setup cloudEOS router by connecting its management interfaces to the device. eno3 and eno4 are aggregated to bonded interface cluster0, and cluster0 is similarly connected to Linux bridge clusterbr. However, they are not used for cloudEOS router setup
Data Traffic Interfaces
The earlier figure shows that the appliance has 4 physical 10G ports --- 10GB1/2/3/4 configured in SR-IOV mode. Each port is partitioned into 32 SR-IOV Virtual Functions to provide 128 virtual interfaces for cloudEOS routerinstances on the appliance. You may optionally configure a VLAN to be used for each virtual interface. The VLAN configuration allows the separation of the broadcast domain for traffic in and out of each physical port. SRIOV NIC handles the VLAN tag, which is transparent to the cloudEOS router. For performance reasons, note that the cloudEOS routerlauncher script creates a cloudEOS router with all its CPU cores and memory from the same NUMA node. Therefore, all required CPU resources for a cloudEOS router must be available on one socket. If required, resources for launching a new cloudEOS router are split across two sockets; the cloudEOS routerlauncher will not be able to launch the cloudEOS router. In such a scenario, the user may need to reconfigure the existing VMs and/or reduce the resource requirements of the new VM to fit within a NUMA node.
Appliance Setup
- Setup Management Connections
- Connect iDRAC (IPMI) to a network device.
- Connect eno1 and eno2 to a network device supporting LACP.
- Make sure the DHCP server is setup properly.
- After the appliance boot up, iDRAC and devicebr (the management bridge interface) will get their DHCP assigned IP addresses.
- Refer to section 2.5.1 - DHCP Based IP Address Setup in Arista'scloudVision Appliance Quick Start Guide for DHCP based IP address setup.
- Refer to section 2.5.2 - Manual IP Address Setup in Arista's cloudVision Appliance Quick Start Guide for Manual based IP address. After manually configuring IP addresses for management interfaces, reboot the appliance instead of restarting the network-service because the appliance setup scripts for DCA-200-veos take effect only during the reboot.
- There are multiple ways to connect to the appliance:
- SSH to devicebr DHCP address.
- Web access to iDRAC https://<hostname or IP of iDRAC using Google Chrome or any other web browser.
- Use the terminals connected to VGA and other peripherals if the management interfaces' DHCP addresses are unknown.
- Login to the appliance using username: root(password: arista). Change appliance username/password appropriately by referring to Chapter 3 - Accessing cloudVision Appliance in Arista cloudVision Appliance Quick Start Guide.
cloudEOS router Installation
Supported router Configurations
Launching/Removing/Query cloudEOS router
The figure in the “Interfaces” section shows the rear view of the appliance and ethernet ports (10GB1/2/3/4) the Wide Area Network launcher script references. The ethernet ports in the cloudEOS router are virtual ethernet ports connected to one of the 10GB1/2/3/4 ports. VLANs are configured on each interface when installing cloudEOS router. The SRIOV NICs do the VLAN tagging. Note that the connected networking devices need to have the same VLANs configured on the trunk port.
The appliances are shipped with a version of the cloudEOS router image found in /data/tools. If you want to install the latest cloudEOS router image, download the desired cloudEOS.qcow2 version from Arista.com to the appliance to another directory.
The cloudEOS router launcher is a Python script named dca-200-veos-setup-vm.py found in the /data/tools directory.
switch# ./dca-200-veos-setup-vm.py --help
usage: dca-200-veos-setup-vm.py [-h] [-n VMNAME] [-m IMAGE] [-d]
[-i [INTERFACE [INTERFACE ...]]] [-s MEMORY]
[-c CORES] [-r [REMOVE [REMOVE ...]]] [-q]
Create/Remove veos instances
optional arguments:
-h, --helpshow this help message and exit
-n VMNAME, --name VMNAME
Name of the veos VM
-m IMAGE, --image IMAGE
Qcow2 image name to use for launching the VM
-d, --debug Print detailed debug info
-i [INTERFACE [INTERFACE ...]], --interface [INTERFACE [INTERFACE ...]]
Interfaces and optional vlans/mac. The interfaces must
be listed in guest interfaces order. The interfase can
be specified either in PCI address format (using lspci
command) Or 10GB1/2/3/4. For example: '-i
10GB1,vlan=10 10GB2 10GB3,vlan=40' or '-i
3b:10.2,vlan=50 3b:10.3,vlan=10 af:10.2 af:10.3'
-s MEMORY, --memory MEMORY
Memory in Gbytes to assign to VM. Default is 4 Gb
-c CORES, --cores CORES
Number of Cores to assign to VM. Default is 4 cores
-r [REMOVE [REMOVE ...]], --remove [REMOVE [REMOVE ...]]
Remove VMs
-q, --query Query info about configured VMs
Example
Below is an example of commands to launch VMs with a core count of 4 (default), 4GB memory (default), and 4 ethernet interfaces.
switch# ./dca-200-veos-setup-vm.py -n veos-router1 -m /tmp/cloudEOS.qcow2 -i 10GB2,vlan=50 10GB1,vlan=10 10GB3,vlan=100 af:10.0,vlan=200
Extracting info for existing VMs: ['']
Total count is: 20, reserved for hypervisor: 2, Total Available: 18
Used CPU count is 0, Free cores 18
intfList is: ['10GB2,vlan=50', '10GB1,vlan=10', '10GB3,vlan=100', 'af:10.0,vlan=200']
Used CPU count is 0, Free cores 18
Free core set on Node 0 : [2, 4, 6, 8, 10, 12, 14, 16, 18]
CPU core used are:[2, 4, 6, 8]
Using PCI interfaces for new VM veos-router1:
('veos-router1', 'et1') --> 10GB2 PCI address: 3b:10.0 vlan 50 mac None
('veos-router1', 'et2') --> 10GB1 PCI address: 3b:10.1 vlan 10 mac None
('veos-router1', 'et3') --> 10GB3 PCI address: af:10.1 vlan 100 mac None
('veos-router1', 'et4') --> 10GB4 PCI address: af:10.0 vlan 200 mac None
- VM will be created with 4 cores by default without specifying the number of cores. The launcher picks core 2,4,6,8 on NUMA node0 for veos-router1.
- A different image “/tmp/cloudEOS.qcow2,” than the default router image (/data/tools/cloudEOS.qcow2) is specified.
- Interfaces MUST be specified in VM interface order (the physical 10GB port eth1, eth2.. in VM) in either 10GBx or PCI address format. In the above example, we used10GBx format and PCI address format to specify 4 interfaces. The interfaces are configured on different VLANs.
- The launcher script will print the guest interface mapping to host 10GB interfaces.
If an error occurs while creating a new VM using the launcher, refer to the chapter's Troubleshooting section for additional information.
The dca-200-veos-setup-vm.py script is used to remove the running VMs. The example below shows how to remove two existing VMs.
switch# ./dca-200-veos-setup-vm.py -r veos-router1 veos-router2
Cleaning up VM:veos-router1
Cleaning up VM:veos-router2
- List of running VMs
- Mapping of running VM interfaces to host interfaces
- Mapping of VM CPUs to host CPUs
Below is an example output:
switch# ./dca-200-veos-setup-vm.py -q
Extracting info for existing VMs: ['veos-router1', 'veos-router2']
Total count is: 20, reserved for hypervisor: 2, Total Available: 18
Used CPU count is 8, Free cores 10
VM veos-router1 :
interfaces:
et1 --> 10GB2 PCI address: 3b:10.0 vlan 50 mac 52:54:00:d4:f4:46
et2 --> 10GB1 PCI address: 3b:10.1 vlan 10 mac 52:54:00:d8:a9:50
et3 --> 10GB3 PCI address: af:10.1 vlan 100 mac 52:54:00:0c:0a:15
et4 --> 10GB4 PCI address: af:10.0 vlan 200 mac 52:54:00:20:4a:67
CPU Core Mapping:
0 --> 2
1 --> 4
2 --> 6
3 --> 8
VM veos-router2 :
interfaces:
et1 --> 10GB4 PCI address: af:10.2 vlan 50 mac 52:54:00:bb:ab:f1
et2 --> 10GB3 PCI address: af:10.3 vlan 10 mac 52:54:00:58:f7:2b
CPU Core Mapping:
0 --> 10
1 --> 12
2 --> 14
3 --> 16
Available free cores:3 5 7 9 11 13 15 17 18 19
Accessing cloudEOS router
- On the appliance virsh console <vm_name>
- Launch browser based VM management tool kimchi to edit/view/console-access of the VMs at https://<management_ip>:8001
Troubleshooting
PCI Addresses for Virtual Functions
[root@cv ~]# ethtool -i 10GB1 | grep bus
bus-info: 0000:3b:00.1
[root@cv ~]# ethtool -i 10GB2 | grep bus
bus-info: 0000:3b:00.0
[root@cv ~]# ethtool -i 10GB3 | grep bus
bus-info: 0000:af:00.1
[root@cv ~]# ethtool -i 10GB4 | grep bus
bus-info: 0000:af:00.0
[root@cv ~]# lspci | grep Ethernet
04:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe
04:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe
3b:00.0 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01)⇐ 10GB2 PF
3b:00.1 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01)⇐ 10GB1 PF
3b:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)⇐ 10GB2 VF
3b:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)⇐ 10GB1 VF
3b:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
3b:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
...
3b:17.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
3b:17.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
5e:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe
5e:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme BCM5720 Gigabit Ethernet PCIe
af:00.0 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01)⇐ 10GB4 PF
af:00.1 Ethernet controller: Intel Corporation Ethernet 10G 2P X520 Adapter (rev 01)⇐ 10GB3 PF
af:10.0 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)⇐ 10GB4 VF
af:10.1 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)⇐ 10GB3 VF
af:10.2 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
af:10.3 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
...
af:17.6 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
af:17.7 Ethernet controller: Intel Corporation 82599 Ethernet Controller Virtual Function (rev 01)
[root@cv ~]# virsh nodedev-list | grep 3b_00_0 ⇐ PF PCI
pci_0000_3b_00_0
[root@cv ~]# virsh nodedev-dumpxml pci_0000_3b_00_0
<device>
<name>pci_0000_3b_00_0</name>
<path>/sys/devices/pci0000:3a/0000:3a:00.0/0000:3b:00.0</path>
<parent>pci_0000_3a_00_0</parent>
<driver>
<name>ixgbe</name>
</driver>
<capability type='pci'>
<domain>0</domain>
<bus>59</bus>
<slot>0</slot>
<function>0</function>
<product id='0x154d'>Ethernet 10G 2P X520 Adapter</product>
<vendor id='0x8086'>Intel Corporation</vendor>
<capability type='virt_functions' maxCount='63'>
<address domain='0x0000' bus='0x3b' slot='0x10' function='0x0'/> ⇐ VF PCI
<address domain='0x0000' bus='0x3b' slot='0x10' function='0x2'/>
<address domain='0x0000' bus='0x3b' slot='0x10' function='0x4'/>
<address domain='0x0000' bus='0x3b' slot='0x10' function='0x6'/>
<address domain='0x0000' bus='0x3b' slot='0x11' function='0x0'/>
<address domain='0x0000' bus='0x3b' slot='0x11' function='0x2'/>
<address domain='0x0000' bus='0x3b' slot='0x11' function='0x4'/>
<address domain='0x0000' bus='0x3b' slot='0x11' function='0x6'/>
<address domain='0x0000' bus='0x3b' slot='0x12' function='0x0'/>
<address domain='0x0000' bus='0x3b' slot='0x12' function='0x2'/>
<address domain='0x0000' bus='0x3b' slot='0x12' function='0x4'/>
<address domain='0x0000' bus='0x3b' slot='0x12' function='0x6'/>
<address domain='0x0000' bus='0x3b' slot='0x13' function='0x0'/>
<address domain='0x0000' bus='0x3b' slot='0x13' function='0x2'/>
<address domain='0x0000' bus='0x3b' slot='0x13' function='0x4'/>
<address domain='0x0000' bus='0x3b' slot='0x13' function='0x6'/>
<address domain='0x0000' bus='0x3b' slot='0x14' function='0x0'/>
<address domain='0x0000' bus='0x3b' slot='0x14' function='0x2'/>
<address domain='0x0000' bus='0x3b' slot='0x14' function='0x4'/>
<address domain='0x0000' bus='0x3b' slot='0x14' function='0x6'/>
<address domain='0x0000' bus='0x3b' slot='0x15' function='0x0'/>
<address domain='0x0000' bus='0x3b' slot='0x15' function='0x2'/>
<address domain='0x0000' bus='0x3b' slot='0x15' function='0x4'/>
<address domain='0x0000' bus='0x3b' slot='0x15' function='0x6'/>
<address domain='0x0000' bus='0x3b' slot='0x16' function='0x0'/>
<address domain='0x0000' bus='0x3b' slot='0x16' function='0x2'/>
<address domain='0x0000' bus='0x3b' slot='0x16' function='0x4'/>
<address domain='0x0000' bus='0x3b' slot='0x16' function='0x6'/>
<address domain='0x0000' bus='0x3b' slot='0x17' function='0x0'/>
<address domain='0x0000' bus='0x3b' slot='0x17' function='0x2'/>
<address domain='0x0000' bus='0x3b' slot='0x17' function='0x4'/>
<address domain='0x0000' bus='0x3b' slot='0x17' function='0x6'/>
</capability>
<iommuGroup number='30'>
<address domain='0x0000' bus='0x3b' slot='0x00' function='0x0'/>
</iommuGroup>
<numa node='0'/>
<pci-express>
<link validity='cap' port='0' speed='5' width='8'/>
<link validity='sta' speed='5' width='8'/>
</pci-express>
</capability>
</device>
cloudEOS routerLauncher Debugging Functionalities
- cloudEOS routerlauncher error messages
- cloudEOS routerlauncher query command
[root@cv /data/tools]# ./dca-200-veos-setup-vm.py -n veos-router2 -m ./cloudEOS.qcow2 -i af:10.0,vlan=50 10GB3,vlan=10
Extracting info for existing VMs: ['veos-router1']
Total count is: 20, reserved for hypervisor: 2, Total Available: 18
Used CPU count is 4, Free cores 14
intfList is: ['af:10.0,vlan=50', '10GB3,vlan=10']
Error: Interface af:10.0 is already assigned to VM veos-router1
[root@cv /data/tools]# ./dca-200-veos-setup-vm.py -n veos-router5 -m ./cloudEOS.qcow2 -i 10GB4,vlan=20 10GB1,vlan=30
Extracting info for existing VMs: ['veos-router1', 'veos-router2', 'veos-router3', 'veos-router4']
Total count is: 20, reserved for hypervisor: 2, Total Available: 18
Used CPU count is 16, Free cores 2
intfList is: ['10GB4,vlan=20', '10GB1,vlan=30']
Free core set on Node 0 : [18]
Free core set on Node 1 : [19]
Not enough CPU cores available on any NUMA node to allocate 4 cores.
The above example shows when user tries to create a VM with 4 cores (by default), an error message points out there’s not enough CPU cores available on any NUMA. It also prints out current free cores on each NUMA node (core 18 on node0 and core 19 on node1). User may choose to reduce the number of cores for new instance or reprovision existing VMs to fit new VM in.
Appliance Setup Debugging
- dca-200-veos-test.sh
- dca-200-veos-test-nics.py
/data/imaging/dca-200-veos-test.sh checks things like hyperthreading, interface MTU and etc.
[root@cv /data/imaging]# ./dca-200-veos-test.sh
Device '10GB1' successfully disconnected.
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/19)
Device '10GB2' successfully disconnected.
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/20)
Device '10GB3' successfully disconnected.
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/21)
Device '10GB4' successfully disconnected.
Connection successfully activated (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/22)
Appliance is correctly set for veos use
/data/imaging/dca-200-veos-test-nics.py creates 4 VMs and sends traffic among them to test NICs are setup properly for creating new VMs and sending traffic.
[root@cv /data/imaging]# ./dca-200-veos-test-nics.py -a -i /data/tools/cloudEOS.qcow2
Cleaning up VMs:['autoDut1']
Cleaning up VMs:['autoDut2']
Cleaning up VMs:['autoDut3']
Cleaning up VMs:['autoDut4']
Creating instance autoDut1
Creating instance autoDut2
Creating instance autoDut3
Creating instance autoDut4
Starting Traffic test on created VMs
Running Tests onautoDut1
Running Tests onautoDut2
Running Tests onautoDut3
Running Tests onautoDut4
All Tests finished Successfully
Cleaning up VMs:['autoDut1']
Cleaning up VMs:['autoDut2']
Cleaning up VMs:['autoDut3']
Cleaning up VMs:['autoDut4']
If there are error messages shown from the above two test scripts, user can run /data/imaging/dca-200-veos-setup.sh to re-setup the appliance. Note, The /data/imaging/dca-200-veos-setup.sh will reconfigure the interfaces and other parameters on the appliance and reboot the VMs, which may affect the running VMs to working properly and stop.
The appliance shipped should be in good condition, and quality checked stage, where setup and test scripts have already been run. So it is NOT recommended for customer to run /data/imaging/dca-200-veos-setup.sh without contacting Arista support.
Supported Transceivers
- -10G-SR
- -10G-SRL
- -10G-LR
- -10G-AOC
- -10G-CR
Limitations
- A physical interface can have up to 32 virtual interfaces (virtual functions).
- NUMA optimization may decrease the number of VMs that the appliance can host. Reprovisioning existing VMs may be necessary to use all resources in case of resource fragmentation.
- CVA upgrades from 2.1.2 to later releases are now supported on DCA-200-veos.
cloud high availability
Amazon Web Services (AWS) and Microsoft Azure, both have cloud resources that are hosted around the world in multiple locations. These locations comprise Regions, separate geographic areas, and availability Zones, which are isolated locations within each Region.
You can distribute cloud resources across multiple regions or locations within a region to ensure fault tolerance. cloud service providers offer features like AWS availability Zones and Azure availability Sets (or Fault Domains) to support high availability. When you deploy cloudEOS routers to enhance your cloud network, you should deploy them as a high availability pair using the cloudEOS router cloud high availability feature that aligns with your cloud's high availability design.
- cloudEOS router instance goes down due to underlying cloud infrastructure issues.
- cloudEOS router instance is unable to forward traffic due to connectivity issues in the cloud infrastructure.
- cloudEOS router experiences an internal issue leading to unavailability.
A cloudEOS router HA paired with cloud HA is an active-active deployment model for a region's cloud high availability designs. Each cloudEOS router in an HA pair provides enhanced routing capabilities as the gateway (or next-hop router for certain destinations) for the subnets to which the cloudEOS routers connect. The two cloudEOS router peers select Bidirectional Forwarding Detection (BFD) between the router interfaces to monitor each other's liveliness. In case of cloud infrastructure issues or cloudEOS router failure, the active cloudEOS router takes over as the gateway or next-hop for the subnets. It modifies the corresponding cloud route table(s) according to pre-configured information through cloud-specific API calls.
cloud HA Topology
This diagram shows an example of a router cloud HA implementation.
In the diagram above, a virtual network is a collection of resources that are in the same cloud region. Within this virtual network, the resources, including routers, deploy into two cloud high availability zones (availability Zones for AWS and Fault Domain for Azure) for fault tolerance reasons.
Within each availability zone, the hosts/VMs and interfaces are connected to their corresponding subnets when the network operates normally. Each subnet is associated with a route table within the cloud infrastructure. Static routes are configured in the cloud route tables so the hosts/VMs' traffic is routed to routers in the corresponding availability zone as gateway or next-hop to reach certain destinations. For example, configure a default route (0.0.0.0/0) in the cloud route table with the next-hop as router's cloud interface ID or IP (varies depending on the cloud). The routing policy or protocol, such as BGP, on the routers are user configurable based on the user's network design.
The two routers in the diagram above are configured with the cloud HA feature as HA peers. The cloud HA on the routers would establish a BFD peering session between the two devices through ethernet or tunnel interfaces.
In the event that the active router identifies a loss of BFD connectivity, the cloud's backup route table will be updated via cloud-specific API to redirect traffic through the active router. As an illustration, if router 2 loses BFD connectivity with its peer, it would modify Route Table 1. This change ensures that traffic originating from hosts within Subnet 1 and Subnet 2, and destined for router 1, is instead directed to the next-hop ID or IP associated with router 2. Traffic from hosts in availability zone 1 would initially be routed to the respective subnet gateways within the cloud. Subsequently, these subnet gateways would forward the traffic to the updated next-hop interface ID or IP on router 2. Upon receiving the traffic, router 2 would then forward it in accordance with its routing table.
If router 1 loses connectivity, hosts behind Subnet 1 and Subnet 2 will be unreachable to the rest of the network because routing protocols like BGP will withdraw the routes.
Subnet 1 and Subnet 2 are not directly connected to router 2. Therefore, a routing strategy to use these two subnets as "backup" on router 2 should be considered when designing your network.
A typical design solution is to configure static routes on the active router (for example, router 2) for the subnets that are connected to the peerrouter (for example, router 1). These static routes should point toward the cloud subnet gateways of the active router and have a high administrative distance value (making them the least preferred route). For example, a static route for peer subnet 10.1.1.0/24 could be configured on router 2 as 'ip route 10.1.1.0/24 10.2.1.1 255' where 10.2.1.1 is the gateway for one of the ethernet interfaces on router 2. These static routes would be advertised when dynamic routing protocols like BGP withdraw or remove the original routes with a lower administrative distance.
When BFD peering session is restored to UP state upon recovery, each active router would restore its locally controlled route table entries (per user configuration) to point to itself as primary gateway again.
Configuring the cloud Proxy
If your deployment uses proxies, you can optionally configure them. This configuration applies to all cloud types and will direct all web traffic for the underlying restful APIs for the cloud provider SDK through the configured proxies. Although you can configure multiple proxies, only one can be used at a time from the cloud high-availability configuration.
router(config)#
router(config)#cloud proxy test
router(config-cloud-proxy-test)#
The following example configures the cloud proxy IP, port, username, and password for HTTP.
router(config)#
router(config)#cloud proxy test
router(config-cloud-proxy-test)#http 1.2.3.4 1234 username test password 7 075E731F1A
router(config-cloud-proxy-test)#
Configuring the cloud Provider
cloud Configuration
To have access to the cloud services, the cloudEOS router must be provided with credentials. Additionally, a proxy may be configured for the connection to the cloud services to go through.
AWS Specific cloud
Complete the following tasks to configure AWS Specific cloud services.
- Configure Credentials
- Access to AWS Specific cloud API Server
- If cloudEOS router is associated with a public IP address, no special configuration is required.
- If cloudEOS router is not associated with an public IP address, either use AWS Private Link or Proxy configuration
Configure Credentials
In the AWS Specific cloud configuration, a region must be specified. It is recommended to authorize the cloudEOS router by assigning it an IAM role, but an explicit credential can also be specified.
- IAM Role Configuration - No credentials. See cloud Provider Helpful Tips for additional information.
- Explicit Credential Configuration
AWS Specific cloud IAM Role Configuration
The IAM role should be configured on the AWS Specific as shown below. This is the recommended configuration.
- "Trust Relationships" has "ec2.amazonaws.com" as trusted entities.
- "Policy" with "Permissions" for the network related EC2 actions.
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:AssociateRouteTable",
"ec2:CreateRoute",
"ec2:CreateRouteTable",
"ec2:DeleteRoute",
"ec2:DeleteRouteTable",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcs",
"ec2:ReplaceRoute",
"ec2:DisassociateRouteTable",
"ec2:ReplaceRouteTableAssociation",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeInstances",
"ec2:DescribeSubnets"
],
"Resource": "*"
}
]
}
This is applicable only when running in AWS cloud environment and configures various aspects of cloud HA feature to interact with AWS web services.
Note: The access-key-id and secret access-key commands are either both configured or both are omitted. If omitted, the cloud HA Agent will try to use AWS IAM role for security tokens to access and control AWS route tables. Verify the IAM role for the cloudEOS router Virtual Machine( VM ) is configured properly on the AWS cloud. Refer to AWS documentation to configure IAM role.
router(config)#
router(config)#cloud provider aws
router(config-cloud-aws)#access-key 0 ATPAILIL5E982IPT7P3R
router(config-cloud-aws)#secret access-key 0 M0RRUtAA8I8wYxJB8
router(config-cloud-aws)#region us-west-1
router(config-cloud-aws)#proxy test
Configure the backup-gateway, primary-gateway, Route Table ID(rtb) and local interface for AWS.
The Route Table ID specifies for AWS the backup-gateway and primary gateway, then the destination selects the individual route within the route table to control. The local-cloud-interface then points to the interface ID eni-867caa86 (from AWS perspective) of the router that the traffic should be directed.
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#aws
router(config-cloud-ha-peer-veos2-aws)#backup-gateway rtb-40b72d24
0.0.0.0/0 local-cloud-interface eni-867caa86
router(config-cloud-ha-peer-veos2-aws)#primary-gateway rtb-2843124c
0.0.0.0/0 local-cloud-interface eni-867caa86
Explicit Credential Configuration
The explicit credential should be configured as shown below.
router(config)#cloud provider aws
router(config-cloud-aws)#region us-west-1
router(config-cloud-aws)#access-key 0 MYEXAMPLESECRETKEY
router(config-cloud-aws)#secret access-key 0 MYEXAMPLESECRETKEY
router(config-cloud-aws)#exit
router(config-cloud)#exit
Azure
- SDK Auth Credentials
To generate SDK Auth Credentials, use the sdk authentication credential-file flash:startup-config command in the config-cloud-azure configuration mode.
router(config)#cloud provider azure router(config-cloud-azure)#sdk authentication credential-file flash:startup-config - Active Directory Credentials
The following example places the router into the config-cloud-azure configuration mode and sets the active directory credentials.
router(config)#cloud provider azure router(config-cloud-azure)#active-directory credential email subscription-id ef16892c-aa46-4aba-ae9a-d4fhsb1c612c
Configuring BFD
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#bfd source-interface tunnel 2 single-hop
Configuring the Recovery Time
The recovery wait-time command in the cloud-ha configuration sub-mode configures the amount of time to take back control of local route tables after failure recovery. The following example shows the wait time is configured to 90 seconds.
router(config-cloud-ha-peer-veos2)#recovery wait-time 90
cloud Provider Helpful Tips
The following are needed for cloud high availability but are not part of the cloudEOS router configuration on the cloudEOS router. These may change or can be another way to achieve the same effect without changing the cloudEOS router.
AWS VPN Specific cloud PrivateLink
AWS VPN Specific cloud PrivateLink allows a private (no public IP address) cloudEOS router instance to access services offered by AWS (without using proxy).
The interface VPC endpoints enables a private cloudEOS router instance to connect to AWS VPN Specific cloud PrivateLink.
To configure Interface VPC Endpoints:
- Open the Amazon VPC console and choose Endpoints in the navigation panel.
- Select Create Endpoint.
- Choose the AWS Services and select service name com.amazonaws.<your-region>.ec2.
- Choose the VPC and the subnets in each availability zone for the Interface VPC endpoints.
- Enable private DNS name and set security group accordingly.
- Select Create Endpoint.
Once the Endpoint(s) is created, the EC2 API IP associated with the domain-name will be updated to the endpoint IP.
Additional interface VPC endpoints information can be found at: https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpce-interface.html
Configuring cloud high availability
To enable the cloud HA and its parameters, use the following configurations.
Enable cloud high availability
The cloud high-availability command places the cloudEOS router in the cloud-ha configuration mode. This example enables cloud high-availability and configures the peer veos2.
router(config)#cloud high-availability
router(config-cloud-ha)#no shutdown
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#
AWS Specific for high availability
This is applicable only when running in AWS cloud environment and configures various aspects of cloud HA feature to interact with AWS web services.
Note: The access-key-id and secret access-key commands are either both configured or both are omitted. If omitted, the cloud HA Agent will try to use AWS IAM role for security tokens to access and control AWS route tables. Verify the IAM role for the cloudEOS router Virtual Machine( VM ) is configured properly on the AWS cloud. Refer to AWS documentation to configure IAM role.
router(config)#
router(config)#cloud provider aws
router(config-cloud-aws)#access-key 0 ATPAILIL5E982IPT7P3R
router(config-cloud-aws)#secret access-key 0 M0RRUtAA8I8wYxJB8
router(config-cloud-aws)#region us-west-1
router(config-cloud-aws)#proxy test
Configure the backup-gateway, primary-gateway, Route Table ID(rtb) and local interface for AWS.
The Route Table ID specifies for AWS the backup-gateway and primary gateway, then the destination selects the individual route within the route table to control. The local-cloud-interface then points to the interface ID eni-867caa86 (from AWS perspective) of the router that the traffic should be directed.
AWS
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#aws
router(config-cloud-ha-peer-veos2-aws)#backup-gateway rtb-40b72d24
0.0.0.0/0 local-cloud-interface eni-867caa86
router(config-cloud-ha-peer-veos2-aws)#primary-gateway rtb-2843124c
0.0.0.0/0 local-cloud-interface eni-867caa86
Azure Specific for high availability
Azure
- SDK Auth Credentials
To generate SDK Auth Credentials, use the sdk authentication credential-file flash:startup-config command in the config-cloud-azure configuration mode.
router(config)#cloud provider azure router(config-cloud-azure)# sdk authentication credential-file flash:startup-config - Active Directory Credentials
The following example places the router into the config-cloud-azure configuration mode and sets the active directory credentials.
router(config)#cloud provider azure router(config-cloud-azure)#active-directory credential email subscription-id ef16892c-aa46-4aba-ae9a-d4fhsb1c612c
Configure the backup-gateway, primary-gateway, Route Table ID (rtb), resource-group and next-hop for Azure
The resource group specified is the one which contains the route table referenced beneath it. The nextHopIp is the IP of the router interface that traffic should be directed.
Azure
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#azure
router(config-cloud-ha-peer-veos2-azure)#backup-gateway Subnet-2-veos-RouteTable 0.0.0.0/0 10.1.1.4 resource-group my_resource_group_64f86970ffe24ab
GCP Specific for high availability
In GCP specific cloud configuration, you must specify a Project. The GCP cloud uses either the Default Credentials, or a Service Account mode for authorization.
- Default Credentials: cloud HA uses the Application Default Credentials for authorization and no configuration is required. Setup a GCP instance with a service account with the requisite permissions. For more information on creating an instance with a service account or changing the service account of an existing instance, refer: https://cloud.google.com/compute/docs/access/create-enable-service-accounts-for-instances
- Service Account: Specify a service account file. For more information on creating a service account file, refer:https://cloud.google.com/iam/docs/creating-managing-service-account-keys#creating_service_account_keys
{
"type": "service_account",
"project_id": "project-id",
"private_key_id": "key-id",
"private_key": "-----BEGIN PRIVATE KEY-----\nprivate-key\n-----END PRIVATE KEY-----\n",
"client_email": "service-account-email",
"client_id": "client-id",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://accounts.google.com/o/oauth2/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/service-account-email"
}
For Default Credentials or Service Account authorization model, the role associated with the cloudEOS instance/service account must have the following permissions:
- compute.networks.get
- compute.networks.updatePolicy
- compute.projects.get
- compute.routes.create
- compute.routes.delete
- compute.routes.get
- compute.routes.list
Example
- cloud HA GCP configuration example.
cloudEos(config)# cloudEos(config)#cloud provider gcp cloudEos(config-cloud-gcp)#project gcp-project-name cloudEos(config-cloud-gcp)#service-account file flash:.gcp_service_account.json cloudEos(config-cloud-gcp)#proxy test
Specify a destination prefix for cloud HA routes on GCP to select the individual routes that we wish to control. Since route table is not present in GCP, you can specify an optional tag for each route to simulate the route table.
cloudEos(config)#cloud high-availability
cloudEos(config-cloud-ha)#peer veos2
cloudEos(config-cloud-ha-peer-veos2)#gcp
cloudEos(config-cloud-ha-peer-veos2-gcp)#backup-gateway 0.0.0.0/0 tag tag2
cloudEos(config-cloud-ha-peer-veos2-gcp)#primary-gateway 0.0.0.0/0 tag tag1
Limitations
- For cloud HA on AWS/Azure, pre-create the HA routes before configuring them on a cloudEOS instance. For GCP, cloud HA automatically creates HA routes; there's no need for pre-creation to avoid route conflicts.
- GCP cloud HA routes don't get automatically deleted from GCP when removed from the cloud HA configuration on the cloudEOS instance; you need to delete them manually from GCP.
- cloud HA on GCP only allows adding routes in the VPC network that corresponds to the cloudEOS instance's first interface (nic0).
- Since GCP routes are added at the VPC level, specify tags to simulate route tables when adding a cloud HA route with the primary-gateway/backup-gateway command. Use the same tag to manually apply cloud HA routes to a subset of instances within the VPC network.
cloudEOS HA GCP provider commands
- cloud provider gcp
- project
- service-account
- primary-gateway
- backup-gateway
- show cloud high-availability routes
- show cloud provider gcp
cloud provider gcp
The cloud provider gcp command places the switch in cloud-provider-gcp configuration mode, and allows you to configure cloud provider gcp command parameters. The exit command returns the router to global configuration mode.
Global Configuration
Command Syntax
cloud provider gcp
- These commands places the cloud provider for GCP into the configuration mode.
router#config router(config)#cloud provider gcp router(config-cloud-gcp)# - The exit command returns to the global configuration mode.
router(config-cloud-gcp)#exit router(config)#
project
The project command specifies the GCP project name. The no project command removes the configuration from the router running-config.
Global cloud Provider GCP Configuration
Command Syntax
project name
no project name
- name Specifies the selected GCP project name.
- These commands configures the GCP project.
router(config)#cloud provider gcp router(config-cloud-gcp)#project test-project - The no project command removes the GCP project.
router(config)#cloud provider gcp router(config-cloud-gcp)#no project test-project
service-account
The service-account specifies the service account file when using the Service Account authorization model. The no service-account command removes the configuration from the router running-config.
Global cloud Provider GCP Configuration
Command Syntax
service-account file sa-file
no service-account file sa-file
- sa-file Specifies the path to the service account file.
- These commands configures the Service Account file used.
router(config)#cloud provider gcp router(config-cloud-gcp)#service-account file flash:.gcp_service_account.json router(config-cloud-gcp)# - The no service-account command removes the Service Account file configuration.
router(config)#cloud provider gcp router(config-cloud-gcp)#no service-account file flash:.gcp_service_account.json router(config-cloud-gcp)#
primary-gateway
The primary-gateway command in the cloud-ha submode adds a primary high availability route for GCP. The no primary-gateway command removes the route configuration from the WAN running-config.
cloud HA GCP Configuration Submode
Command Syntax
primary-gateway dest-prefix [tag rt-tag]
no primary-gateway dest-prefix [tag rt-tag]
- dest-prefix Specifies the destination IP prefix.
- rt-tag Specifies the route tag.
- These commands configures a primary high availability route.
router(config)#cloud high-availability router(config-cloud-ha)#peer veos2 router(config-cloud-ha-peer-veos2)#gcp router(config-cloud-ha-peer-veos2-azure)#primary-gateway 10.1.0.0/16 tag tag1 - The no primary-gateway command removes the primary high availability route configuration.
router(config)#cloud high-availability router(config-cloud-ha)#peer veos2 router(config-cloud-ha-peer-veos2)#gcp router(config-cloud-ha-peer-veos2-azure)#no primary-gateway 10.1.0.0/16 tag tag1
backup-gateway
The backup-gateway command in the cloud-ha submode adds a backup high availability route for GCP. The no backup-gateway command removes the route configuration from the WAN running-config.
cloud HA GCP Configuration Submode
Command Syntax
backup-gateway dest-prefix [tag rt-tag]
no backup-gateway dest-prefix [tag rt-tag]
- dest-prefix Specifies the destination IP prefix.
- rt-tag Specifies the route tag.
- These commands configures a backup high availability route.
router(config)#cloud high-availability router(config-cloud-ha)#peer veos2 router(config-cloud-ha-peer-veos2)#gcp router(config-cloud-ha-peer-veos2-azure)#backup-gateway 10.1.0.0/16 tag tag2 - The no primary-gateway command removes the backup high availability route configuration.
router(config)#cloud high-availability router(config-cloud-ha)#peer veos2 router(config-cloud-ha-peer-veos2)#gcp router(config-cloud-ha-peer-veos2-azure)#no backup-gateway 10.1.0.0/16 tag tag2
show cloud high-availability routes
The show cloud high-availability routes commanddisplays the configured local or peer route table, destination IP address and local Next Hop Interface.
EXEC
Command Syntax
show cloud high-availability routes
- The show cloud high-availability routes command displays high availability routes information.
router(config)#show cloud high-availability routes Peer Route TypeDestination Tag ------ ------------ -------------- ------ peer primary21.2.3.14/24 peer primary1.2.3.4/21 tag1 peer backup 1.2.3.4/21 tag2 peer backup11.2.3.4/21 az1
show cloud provider gcp
The show cloud provider gcp command displays cloud provider information for the GCP platform.
EXEC
Command Syntax
show cloud provider gcp
- The show cloud provider gcp command displays the GCP cloud configuration for Default Credentials authorization model. .
router(config)#show cloud provider gcp Project: project-123 Authentication mode: default credentials Service account file: Proxy: myProxyName - The following example displays the GCP cloud configuration for Service Account authorization model.
router(config)#show cloud provider gcp Project: project-123 Authentication mode: service account Service account file: flash:.gcp_service_account.json Proxy: myProxyName
Full Configurations
AWS VPN Specific cloud Full Configuration
The following AWS configuration is valid for use with the IAM role.
cloud provider aws
region us-west-1
!
cloud high-availability
no shutdown
!
peer veos2
aws
backup-gatewayrtb-40b72d24 0.0.0.0/0 local-cloud-interface eni-26cb1d27
backup-gatewayrtb-17b32973 0.0.0.0/0 local-cloud-interface eni-1589e714
backup-gatewayrtb-54503330 0.0.0.0/0 local-cloud-interface eni-56cf1957
primary-gateway rtb-a4be24c0 0.0.0.0/0 local-cloud-interface eni-26cb1d27
primary-gateway rtb-40b72d24 0.0.0.0/0 local-cloud-interface eni-56cf1957
primary-gateway rtb-63b02a07 0.0.0.0/0 local-cloud-interface eni-1589e714
peer address 10.2.201.149
recovery wait-time 5
bfd source-interface Ethernet1
!
Azure Full Configuration
The following Azure configuration is valid for the MSI.
cloud high-availability
no shutdown
!
peer veos2
azure
backup-gateway Subnet-2-veos-RouteTable 0.0.0.0/0 10.1.2.4 resource-group cloudHaAzure
backup-gateway Subnet-2-veos-RouteTable 10.1.0.0/16 10.1.2.4 resource-group cloudHaAzure
backup-gateway Subnet-3-veos-RouteTable 10.1.0.0/16 10.1.3.4 resource-group cloudHaAzure
backup-gateway Subnet-3-veos-RouteTable 0.0.0.0/0 10.1.3.4 resource-group cloudHaAzure
primary-gateway Subnet-1-veos-RouteTable 10.1.0.0/16 10.1.1.4 resource-group cloudHaAzure
primary-gateway Subnet-1-veos-RouteTable 0.0.0.0/0 10.1.1.4 resource-group cloudHaAzure
peer address 10.1.0.5
recovery wait-time 10
bfd source-interface Ethernet1
cloud HA GCP Full Configuration
- The following GCP configuration uses default credentials.
cloudEOS - 1
cloud provider gcp project gcp-project-name ! cloud high-availability no shutdown ! peer cloudEOS2 gcp backup-gateway 0.0.0.0/0 tag tag1 backup-gateway 0.0.0.0/0 tag tag2 primary-gateway 0.0.0.0/0 tag tag3 primary-gateway 0.0.0.0/0 tag tag4 peer address 10.3.0.59 recovery wait-time 5 bfd source-interface Ethernet1 ! - cloudEOS - 2
cloud provider gcp project gcp-project-name ! cloud high-availability no shutdown ! peer cloudEOS1 gcp backup-gateway 0.0.0.0/0 tag tag3 backup-gateway 0.0.0.0/0 tag tag4 primary-gateway 0.0.0.0/0 tag tag1 primary-gateway 0.0.0.0/0 tag tag2 peer address 10.3.0.59 recovery wait-time 5 bfd source-interface Ethernet1 !
General Troubleshooting Tips
If the cloud HA feature is not working as expected, follow these tips for debugging.
- Network Connectivity and DNS: Ensure network connectivity and proper DNS server setup for this feature to function.
- Proxy and IAM Role (AWS): When using a proxy and IAM role within AWS, ensure that HTTP traffic (TCP port 80) is not proxied. This allows cloudEOS router instances to retrieve temporary security credentials.
- BFD Source Interface: Use a corresponding BFD source interface on the peer cloudEOS router instance. This ensures that BFD traffic ingress and egress utilize the same interface on each instance.
- AWS IAM Role Issue: If the IAM role doesn't work within an AWS cloud environment, temporarily use the access key ID and secret access key with sufficient permissions. This will confirm the rest of the cloud HA configuration while you debug the IAM role policy.
Caveats and Limitations
- From EOS release 4.20.5.A1 onwards, cloud HA only supports CLI-based configuration. JSON-based configurations (used in release 4.20.5F) are unsupported and will not function after image upgrades or downgrades. To upgrade, administrators must manually convert existing JSON configurations to CLI format. Downgrades will work if the older JSON file remains in the /mnt/flash directory.
- For Azure cloud HA, only a single resource group is supported across all routing entries.
- cloud HA currently supports only one peer.
- The AWS IAM role or Azure MSI must be correctly configured using the cloud provider's tools, with sufficient permissions for the cloudEOS router instance to access and update route table entries.
- The cloudEOS router instance requires connectivity to the cloud provider's web services, directly or via proxy (like AWS private-link).
- The recovery wait time should be 10 seconds to prevent route flapping due to temporary instabilities.
- Although cloud HA validates cloud configurations for consistency and permissions, administrators should avoid changing provider network configurations after setup to prevent failover issues.
- BFD connectivity issues between cloudEOS router peers will cause each instance to handle the other's traffic. This cross-traffic forwarding should maintain active-active functionality, although both instances will report as fail-over. Normal traffic patterns resume after connectivity is restored.
- BFD parameters for the cloud HA session can be adjusted using standard BFD commands. Failover and takeover times directly correlate with BFD failure detection time; overly aggressive BFD settings may increase overhead and instability during traffic bursts. The default BFD interval (300 msec, multiplier 3) is recommended.
- To prevent traffic loops, the BFD source interface in cloud HA should not be routable via route tables controlled by the cloudEOS router instance.
- Invalid cloud HA states that mismatched cloud provider configurations require a forced update of the cloud HA configuration (e.g., shut/no shut) after the provider configuration is corrected. cloud HA will not automatically retry the back-end configuration check if it was previously invalid.
cloud high availability Commands
Global
cloud Provider Commands
Global
cloud Proxy Commands
Global
InterfaceShow Commands
EXEC
cloud high availability CLIs
The cloud high availability CLIs are divided into three separate configuration modes:
• cloud Proxy - For proxy related configuration such as http and https.
• cloud Provider - For cloud provider specific configuration such as region, credential, and proxy name.
• cloud high-availability - For configurations such as route, next-hop, BFD source interface, and peer.
access-key-id (cloudEOS router-AWS)
The cloud provider AWS command places the cloudEOS router in cloud-provider-aws configuration mode. This configuration mode allows user to configure cloud provider aws access-key-id command parameters. The no access-key-id command removes the configuration from the cloudEOS router running-config. The exit command returns the cloudEOS router to global configuration mode.
Command Mode
cloud Provider AWS Configuration
Command Syntax
access-key-id Password_Type
no access-key-id Password_Type
Parameters
Password_Type
- 0 access-key-id The password is a clear-text string. Equivalent to no parameter.
-
7 encrypted_key The password is an encrypted string.
- Text
Example
The following example configures the AWS access key to encrypted.
router(config)#cloud provider aws
router(config-cloud-aws)#access-key 0 565656 test
Example
The following example removes the AWS access key and returns the veos to Global configuration mode.
router(config-cloud-aws)#access-key 0 565656 test
router(config-cloud-aws)#no access-key 0 565656 test
router(config)#
Example
The following example returns the veos to Global configuration mode.
router(config-cloud-aws)#access-key 0 565656 test
router(config-cloud-aws)#exit
router(config)#
active-directory credential email subscription-id (cloudEOS router-Azure)
The active-directory credential email subscription-id command configures Azure's cloud provider azure active-directory credential parameters. The no active-directory command removes the configuration from the cloudEOS router running-config. The exit command returns the cloudEOS router to global configuration mode.
Command Mode
cloud Provider Azure Configuration
Command Syntax
active-directory credential email subscription-id ID
no active-directory credential email subscription-id
Parameters
- ID Defines the active directory subscription ID.
Example
The following example places the cloud provider for Azure into the configuration mode.
router(config)#cloud provider azure
router(config-cloud-azure)#active-directory credential email subscription-id
Example
router(config)#cloud provider azure
router(config-cloud-azure)#active-directory credential email subscription-id
azure (cloudEOS router - Azure)
The azure command in the cloud-ha-peer configuration sub-mode, accessible through the cloud-ha configuration mode, allows the user to configure cloud high-availability peer related parameters. The exitcommand returns the cloudEOS router to the to the cloud-ha-peer configuration mode.
Command Mode
Global cloud high availability Peer Configuration Submode
Command Syntax
azure
Example
The following example configures the peer related information for Azure.
router(config)#cloud high-availability
router(config-cloud-ha)#peer p
router(config-cloud-ha-peer-veos2)#azure
router(config-cloud-ha-peer-veos2-azure)#
Example
The following example returns the cloudEOS router to the cloud-ha configuration mode.
router(config-cloud-ha-peer-veos2-azure)#exit
router(config-cloud-ha-peer-veos2)#
backup-gateway (cloudEOS router - Azure)
The cloud high-availability command in the cloud-ha submode assigns the backup gateway parameters for the Azure high availability peered cloud. The no backup-gateway command removes the configuration from the cloudEOS router running-config. The exit command returns the cloudEOS router to global configuration mode.
Command Mode
cloud HA azure configuration submode
Command Syntax
backup-gateway [Azure Rt_Info] resource-group [Name]
no backup-gateway
Parameters
- Azure Rt_Info
- azure-rt-name The azure route name.
- dest-ip-address/mask The destination IP address.
- local-ip-address The local IP address.
- resource-group
- Name Azure resource group name.
Example
The following example configures the parameters for the Azure high availability peered cloud.
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#azure
router(config-cloud-ha-peer-veos2-azure)#backup-gateway Rt1 10.10.1.1/10 1.1.1.1 resource-group test
Example
The following example removes the backup-gateway parameters for the Azure high availability peered cloud.
router(config-cloud-ha-peer-veos2-azure)#no backup-gateway Rt1 10.10.1.1/10
router(config-cloud-ha-peer-veos2-azure)#
bfd source-interface (cloudEOS router)
The bfd source-interface command in the cloud-ha configuration submode configures BFD source interface parameters for the high availability peer. The no bfd source-interface command removed the BFD configurations from the cloudEOS router running-config.
Command Mode
Global cloud HA peer configuration mode
Command Syntax
bfd source-interface [Interface_Type] single-hop
no bfd source-interface
Parameters
- Interface_Type
- Ethernet Ethernet Port number <1-4>.
- Loopback Loopback interface <0-1000>.
- Tunnel Tunnel interface <0-255>.
- Single-hop Single hop BFD . Default is multi-hop.
Example
The following example configures Ethernet 1 as the source interface for BFD and multi-hop set as the default .
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#bfd source-interface ethernet 1
Example
The following example configures Tunnel 2 as a single hop the source interface for BFD.
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#bfd source-interface tunnel 2 single-hop
Example
The following example removes the BFD configuration.
router(config-cloud-ha-peer-veos2)#no bfd source-interface
cloud high-availability peer
Configures one peer at a time into high availability.
Command Mode
Global cloud HA configuration submode
Command Syntax
config-cloud-ha-peer <peer name>
Example
The following example configures the peer and places it in the cloud high availability configuration mode.
router(config)#cloud high-availability peer peer1
router(config-cloud-ha-peer-peer1)#
cloud high-availability shutdown (cloudEOS router)
The shutdown command in the cloud-ha configuration mode disables high availability for virtual EOS instances running in the cloud environment.
Command Mode
cloud high availability configuration
Command Syntax
shutdown
Example
The following example configures the peer and places it in the cloud high availability configuration mode.
router(config)#cloud high-availability
router(config-cloud-ha)#shutdown
cloud provider aws (cloudEOS router)
The cloud provider aws command places the cloudEOS router in cloud-provider-aws configuration mode. This configuration mode allows user to configure cloud provider aws command parameters. The exit command returns the cloudEOS router to global configuration mode.
Command Mode
Global Configuration
Command Syntax
cloud provider aws
Example
The following example places the cloud provider for AWS into the configuration mode.
router#config
router(config)#cloud provider aws
router(config-cloud-aws)#
Example
The following example returns to the global configuration mode.
router(config-cloud-aws)#exit
router(config)#
cloud provider azure (cloudEOS router)
The cloud provider azure command places the cloudEOS router in cloud-provider-azure configuration mode. This configuration mode allows user to configure cloud provider azurecommand parameters. The exit command returns the cloudEOS router to global configuration mode.
Command Mode
Global Configuration
Command Syntax
cloud provider azure
Example
router(config)#cloud provider azure
router(config-cloud-azure)#
cloud proxy (cloudEOS router)
The cloud proxy command places the cloudEOS router in cloud-proxy configuration mode. This configuration mode allows user to configure the cloud proxy command parameters. The no cloud proxy command disables the named proxy and returns the cloudEOS router to global configuration mode.
Command mode
Global Configuration
Command Syntax
cloud proxy proxy_name
no cloud proxy proxy_name
Parameters
proxy_name The proxy name to configure.Example
The following example configures the cloud proxy configuration setting for "test".
router(config)#
router(config)#cloud proxy test
router(config-cloud-proxy-test)#
Example
This command disables the cloud proxy named "test" and returns the veos to global configuration mode.
router(config-cloud-proxy-test)# no cloud proxy test
router(config)#
http (cloudEOS router)
The http command in the cloud-proxy configuration submode configures the IP, port, username, and password parameters. The no http command removes the configured cloud proxy information for HTTP from the running-config and returns the cloudEOS router to the global configuration mode.
Command mode
Global cloud Proxy Configuration
Command Syntax
http [proxy_IP_port] [username] [password]
no http [proxy_IP_port] [username] [password]
Parameters
- proxy_IP_port Port number to be used for the HTTP server. Options include:
- proxy-ip IP address used for the HTTPs proxy. Dotted decimal location.
- proxy_port HTTPS proxy port. Value ranges from 1 to 65535.
- username Name string.
- password Password string.
- 0 cleartext-passwd Indicates the cleartext password is in clear text. Equivalent to the no parameter case.
- 7 encrypted_passwd Indicates encrypted password is md5 encrypted.
Example
The following example configures the cloud proxy IP, port and username and password for HTTP.
router(config)#cloud proxy test
router(config-cloud-proxy-test)# http 1.2.3.4 1234 username test password 7 075E731F1A
router(config-cloud-proxy-test)#
Example
The following example removes the configured cloud proxy information for HTTP from the running-config.
router(config-cloud-proxy-test)# no http 1.2.3.4 1234 username test password 7 075E731F1A
router(config-cloud-proxy-test)#
https (cloudEOS router)
The https command in the command in the cloud-proxy configuration submode configures the IP, port, username and password parameters. The no https command removes the configured cloud proxy information for HTTPS from the running-config and returns the cloudEOS router to global configuration mode.
Command mode
Global cloud Proxy Configuration
Command Syntax
https [[proxy_IP_port] [username]] [password]
no https [[proxy_IP_port] [username]] [password]
Parameters
- proxy_IP_port Port number to be used for the HTTP server. Options include:
- proxy-ipIP address used for the HTTPs proxy. Dotted decimal location.
- proxy_port HTTPS proxy port. Value ranges from 1 to 65535.
- username Name string.
- password Password string.
- 0 cleartext-passwd Indicates the cleartext password is in clear text. Equivalent to the no parameter case.
- 7 encrypted_passwd Indicates encrypted password is md5 encrypted.
Example
The following example configures the cloud proxy IP and port for HTTPS.
router(config)#
router(config)#cloud proxy test
router(config-cloud-proxy-test)#https 10.3.255.155 8888
Example
The following example removes the configured cloud proxy HTTPS information from the running-config.
router(config-cloud-proxy-test)#no https 10.3.255.155 8888
router(config-cloud-proxy-test)#
peer (cloudEOS router)
The peer command in the cloud-ha configuration mode identifies which peer to configure by name. The peer command in the cloud-ha configuration submode configures the cloud high-availability resource group peer related parameters. The no peer command removes the configuration from the cloudEOS router running-config. The exitcommand returns the cloudEOS router to the cloud-ha configuration mode.
Command Mode
cloud high availability Configuration
cloud high availability Configuration Submode
Command Syntax
peer ip-address
no peer ip-address
Parameters
- IP-addressThe peer IP address.
Example
The following example configures the cloud high availability peer.
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#
Example
The following example configures the peer IP address as 10.10.10.149.
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#peer 10.10.10.149
Example
The following example removes the peer IP address from the veos running-config.
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#no peer 10.10.10.149
primary gateway (cloudEOS router - Azure)
The primary-gateway command in the cloud-ha submode assigns the primary gateway parameters for the Azure high availability peered cloud. The no primary-gateway command removes the configuration from the cloudEOS router running-config.
Command Mode
cloud HA Azure Configuration Submode
Command Syntax
primary-gateway [Azure Rt_Info] resource-group [Name]
no primary-gateway [Azure Rt_Info]
Parameters
- Azure Rt_Info
- azure-rt-name The azure route name.
- dest-ip-address/mask The destination IP address.
- local-ip-address The local IP address.
- resource-group
- Name Azure resource group name.
Example
The following example configures the parameters for the Azure high availability peered cloud.
router(config)#cloud high-availability
router(config-cloud-ha)#peer veos2
router(config-cloud-ha-peer-veos2)#azure
router(config-cloud-ha-peer-veos2-azure)#primary-gateway Rt1 10.10.1.1/10 1.1.1.1 resource-group test
Example
The following example removes the primary-gateway parameters for the Azure high availability peered cloud.
router(config-cloud-ha-peer-veos2-azure)#no primary-gateway Rt1 10.10.1.1/10
router(config-cloud-ha-peer-veos2-azure)#
proxy (cloudEOS router)
The proxy command configures the cloud provider aws proxy. The no proxy command removes the configuration from the running-config. The exit command returns the cloudEOS router to global configuration mode.
Command Mode
Global cloud AWS Configuration
Command Syntax
proxy <proxy_name>
no proxy <proxy_name>
Parameters
- proxy_name Proxy name to configure.
Example
The following example configures the Azure cloud proxy named "test".
router(config)#cloud provider aws
router(config-cloud-aws)#proxy test
recovery (cloud HA peer)
The recovery wait-time command in the cloud-ha-peer configuration submode defines the amount of time, in seconds, to take control of the local route tables after failure recovery.
Command Mode
cloud HA peer configuration
Command Syntax
recovery wait-time <time-in-secs>
no recovery wait-time <time-in-secs>
Parameters
- time-in-secs The defined amount of time to take back control of local route tables after failure recovery. Default is 30 seconds.
Example
The following example configures the recovery wait time to 90 seconds.
router(config)#cloud ha
router(config-cloud-ha)#p1
router(config-cloud-ha-p1)#recovery wait-time 90
recovery wait-time (cloudEOS router)
The recovery wait-time command in the cloud-ha configuration sub-mode allows takes back control of local route tables after failure recovery. The no recovery wait-time command removes the configuration from the cloudEOS router running-config. Default is set at 30 seconds.
Command Mode
cloud high availability peer configuration
Command Syntax
recovery wait-time <period>
no recovery wait-time <period>
default recovery wait-time <period>
Parameters
- periodThe defined amount of time to take back control of local route tables after failure recovery. Default is 30 seconds.
Example
The following example shows the wait time is configured to 90 seconds.
router(config-cloud-ha-peer1)#recovery wait-time 90
Example
The following example removes the configured the wait time.
router(config-cloud-ha-peer1)#no recovery wait-time
Example
The following example configures the wait time to the default of 30 seconds.
router(config-cloud-ha-peer1)#default recovery wait-time
region (cloudEOS router - AWS)
The cloud provider aws command places the cloudEOS router in cloud-provider-aws configuration mode. This configuration mode allows user to configure AWS cloud provider region command parameters. The no region command removes the configuration from the cloudEOS router running-config. The exit command returns the cloudEOS router to global configuration mode.
Command Mode
Global cloud Provider AWS Configuration
Command Syntax
region aws-region
no region aws-region
Parameters
- aws-region Specifies the selected region.
Example
The following example configures the cloud provider AWS region.
router(config)#cloud provider aws
router(config-cloud-aws)#region us-west-1
router(config-cloud-aws)#
Example
The following example removes the cloud provider AWS region.
router(config)#cloud provider aws
router(config-cloud-aws)#no region us-west-1
router(config-cloud-aws)#
secret-access_key (cloudEOS router - AWS)
The cloud provider aws command places the cloudEOS router in cloud-provider-aws configuration mode. This configuration mode allows user to configure cloud provider aws secret access-key command parameters. The no secret access-key command removes the configuration from the cloudEOS router running-config. The exit command returns the cloudEOS router to global configuration mode.
Command Mode
Global cloud Provider AWS configuration
Command Syntax
secret access-key password_type
no secret access-key password_type
Parameters
- 0 access-key-idThe password is a clear-text string. Equivalent to no parameter.
- 7 encrypted_key The password is an encrypted string.
- Text
Example
The following example configures the AWS secret access key.
router(config)#cloud provider aws
router(config-cloud-aws)#secret access-key 0 565656 test
router(config-cloud-aws)#
Example
The following example removes the secret access key from the cloudEOS router running-config.
router(config-cloud-aws)#no secret access-key 0 565656 test
router(config-cloud-aws)#
Example
The following example returns the veos to Global configuration mode.
router(config-cloud-aws)#secret access-key 0 565656 test
router(config-cloud-aws)#exit
router(config)#
show cloud high-availability (cloudEOS router)
The show cloud high-availability command displays the high availability configured settings.
Command Mode
EXEC
Command Syntax
show cloud high-availability
Example
This command displays details and status of the cloud high-availability configuration.
router#show cloud high-availability
cloud HA Configuration:
Peer address: 10.2.201.149
Source interface: Ethernet1
Enabled : True
Failover recovery time: 5
Status: valid
State : ready
Last failover time: never
Last recovery time: never
Last config validation start time : 0:26:08 ago
Last config validation end time : 0:26:06 ago
Failovers : 0
show cloud high-availability routes
The show cloud high-availability routes command displays the configured local or peer route table, destination IP address and local Next Hop Interface.
Command Mode
EXEC
Command Syntax
show cloud high-availability routes
Example
The example below displays high availability routes information.
router(config)#show cloud high-availability routes
Peer RouteType RouteID Destination Next Hop Interface
----------- ----------- -------------- ---------- ------------
veos6 primary rtb-1dc75679 0.0.0.0/0eni-e61d95e7
veos6 primary rtb-a29617c6 0.0.0.0/0eni-69109868
veos6 primary rtb-acc756c8 0.0.0.0/0eni-7f1d957e
veos6 backuprtb-43c65727 0.0.0.0/0eni-7f1d957e
veos6 backuprtb-71c65715 0.0.0.0/0eni-e61d95e7
veos6 backuprtb-aca223c8 0.0.0.0/0eni-69109868
show cloud provider aws (cloudEOS router - AWS)
The show cloud provider aws command displays cloud provider information for the AWS platform.
Command Mode
EXEC
Command Syntax
show cloud provider aws
Example
The following example displays the AWS cloud configuration.
router#show cloud provider aws
cloud AWS Configuration
Region : us-west-1
Access key ID:
Access secret key:
Proxy: test
Example
The following example displays the primary and backup gateway information for the AWS cloud provider.
router#show run section cloud cloud provider aws us-west-1 proxy test ! cloud high-availability no shutdown ! peer veos12 aws backup-gateway rtb-40b72d24 0.0.0.0/0 local-cloud-interface eni-26cb1d27 backup-gateway rtb-17b32973 0.0.0.0/0 local-cloud-interface eni-1589e714 backup-gateway rtb-54503330 0.0.0.0/0 local-cloud-interface eni-56cf1957 primary-gateway rtb-a4be24c0 0.0.0.0/0 local-cloud-interface eni-26cb1d27 primary-gateway rtb-e64b2882 0.0.0.0/0 local-cloud-interface eni-56cf1957 primary-gateway rtb-63b02a07 0.0.0.0/0 local-cloud-interface eni-1589e714 peer address 10.2.201.149 recovery wait-time 5 bfd source-interface Ethernet1 ! cloud proxy test https 10.3.255.155 8888
show cloud provider azure (cloudEOS router - Azure)
The show cloud provider azure command displays Azure cloud provider information.
Command Mode
EXEC
Command Syntax
show cloud provider azure
Example
The following example displays the Azure cloud configuration.
router#show cloud provider azure
cloud Azure Configuration:
Active credentials : SDK authentication credential file
SDK auth credentials file: flash:
Proxy name :
Active directory credentials :
show cloud proxy
The show cloud proxy command displays cloud proxy information.
Command Mode
EXEC
Command Syntax
show cloud proxy [<proxy_name>]
Parameters
- proxy_name Identifies the selected proxy by name.
Example
#show cloud proxy [<proxy_name>]
Proxy Name : MyProxyName
Http proxy : 1.2.3.4:8080
Https proxy : 1.2.3.4:4443
Proxy user : proxyuser1
Proxy password : obfuscatedpassword













