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.

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.

The specifications of the Arista AMI are:

Methods for Launching cloudEOS router Instances

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/).

Complete these steps to launch cloudEOS router instances using AWS cloudFormation.
  1. Log in to the Amazon Management Console.
  2. Choose Services > cloudFormation.

    The cloudFormation page will appear, showing the current stacks available for use.

     

  3. Click the Create Stack button.

    The page refreshes, showing the options for specifying the details for the stack.

     

  4. 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.

     

  5. 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=

     

  6. Review the details and make changes if needed.
  7. Click the Create button to create the stack.

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

  9. 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.

     

  10. 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

 

You can launch cloudEOS router instances in the VPCs of your AWS deployment using the EC2 AWS Marketplace. By obtaining the required Amazon Machine Image (AMI) from the AWS Marketplace, you can create and configure these instances. The process includes creating an EC2 key pair, selecting the AMI to configure the instance's operating system, choosing the instance type, and configuring advanced details (optional) for the instance.

Available Options

During this configuration procedure, choose to configure some options to take advantage of certain features. These optional configuration items are:
  • 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:
  • 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.

Complete the following steps to launch a cloudEOS router instance.
  1. Log in to the Amazon Management Console.
  2. 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.

     

  3. Go to the EC2 Dashboard.
  4. From the EC2 Dashboard, click Instances in the left pane.

    The Launch Instance page appears.

     

  5. Click the Launch Instance button.

    The page appears for you to select an AMI.

     

  6. 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.

     

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

     

  8. Click the left pane.

    Choose an Instance Type page appears.

    Select an instance type that meets the requirements for the cloudEOS router instance.

  9. Click the Next: Configure Instance Details button (lower right part of the page).

    The Configure Instance Details page appears.

     

  10. (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.)
  11. (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:
  12. From the Configure Instance Details page, click the Review and Launch button.

    The Review Instance Launch page appears.

     

  13. Click the Launch button.

    A dialog appears when selecting a key pair.

  14. 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.

  15. 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.

     

  16. Make sure the Instance State shows running. Wait for the status to update to running.
  17. (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.
  18. (Optional) Click the Connect button near the top of the page.

    The Connect to Your Instance dialog appears.

     

  19. 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.

Note: To manually install or uninstall the awslogs.swix cloudEOS router extension, see https://aristanetworks.force.com/AristaCommunity/s/article/packaging-and-installing-eos-extensions. To obtain the awslogs.swix cloudEOS router extension, contact Arista TAC if required.

 

Where to find cloudEOS router logs

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.

Modifying AWS log configuration
Modify the AWS log configuration by:
  • 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:

To use the existing subnet and security group for the cloudEOS router instance, make sure to have the following information:
  • Subnet ID
  • Names of the security groups

     

Obtain this information by viewing the instance details.

Procedure

Complete these steps to create network interfaces.

  1. Go to the EC2 Dashboard.
  2. In the NETWORK & SECURITY menu on the left part of the page, select Network Interfaces.

    The page refreshes to show all of the current network interfaces.

     

  3. Select the Create Network Interface button.

    The Create Network Interface dialog appears.

     

  4. Do the following:
    1. Enter a description for the network interface.
    2. Select the subnet for the network interface. (This can be the existing subnet for the cloudEOS router instance or a different subnet.)
    3. Type the names of the security groups for the network interface. (Specify the existing security groups for the cloudEOS router instance or different security groups.)

       

  5. Select the Yes, Create button.

    The new network interface is added to the list of interfaces on the page.

  6. Repeat Step 3 through Step 5 to create additional interfaces as needed.
  7. For each network interface created, complete Steps a and b:
    1. Select the interface, then choose Actions > Change Source/Dest Check.

      The Change Source/Dest Check dialog appears, showing the name of the selected network interface.

    2. Select the Disabled option, then click the Save button.

     

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.

  1. Go to the EC2 Dashboard.
  2. Open the INSTANCES menu on the left side of the page, then click Instances.

    The page lists all of the current network interfaces.

     

  3. Select the cloudEOS router instance to attach a newly created network interface.
  4. Choose Actions > Networking > Attach Network Interface.

    The Attach Network Interface dialog appears.

     

  5. Using the Network Interface menu, select the new network interface created to attach to the instance.
  6. Click the Attach button.
  7. Use the show interfaces command on the cloudEOS router instance to view the new network interfaces created.
    cloudEOS and router# show interfaces
    Ethernet1 is up, line protocol is up (connected)
     Hardware is Ethernet, address is 0235.4079.d2a8 (bia 0235.4079.d2a8)
     Ethernet mtu 8973 bytes, BW 10000000 kbit
     Full-duplex, 10Gb/s, auto negotiation: off, uni-link: n/a
     Up 20 minutes, 42 seconds
     [...]
    Ethernet2 is up, line protocol is up (connected)
     Hardware is Ethernet, address is 0287.4ba7.1f88 (bia 0287.4ba7.1f88)
     Ethernet mtu 8973 bytes, BW 10000000 kbit
     Full-duplex, 10Gb/s, auto negotiation: off, uni-link: n/a
     Up 20 minutes, 42 seconds

     

  8. Repeat Steps 1 through 7 to attach new network interfaces to 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.

Complete these steps to configure the route table of the AWS router.
  1. Log in to the AWS router.
  2. Select the network interface that is attached to a cloudEOS router instance.
  3. Obtain the Subnet ID and the route table ID corresponding to the subnet in which the cloudEOS router instance resides.

    Example:

    Subnet ID (subnet-1c68b744).

    Route table ID (rtb-934cf9f7).

  4. Edit the route table entry to point to the corresponding interface of the cloudEOS router in that subnet.

    Example:

    To reach any subnet other than 10.2.0.0/24, enter the Target to be the network interface ID of the locally connected interface of the cloudEOS router.

     

  5. (Optional) Repeat Steps 2 through 4 to modify route table entries for additional cloudEOS router instances.

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.

Note: It is recommended that you test cloudEOS router configurations on a cloudEOS router or EOS device before using them to deploy a new cloudEOS router.

 

Requirements for Uploading User-data
To ensure that the user data is accepted on upload, make sure the user data meets the following requirements:
  • 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.

List of Start and End Markers to Use This table lists the start and end markers to use when configuring the EOS, AWS, cloudwatch, and cloud HA entities. For each specific entity, the configuration file and the configuration file's location (file path) are given.
Table 1. List of Start and End Markers to Use
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.

The sample contains lines to configure:
  • 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

Based on the Arista EOS, the cloudEOS router runs as a virtual machine instance on Azure. Use the cloudEOS router to create the various types of virtual machine router instances you need for your Azure deployment—for example, gateway routers and transit routers.

Launching a cloudEOS router Azure Instance

Two methods can be used to launch a cloudEOS router instance.

Below is a summary of each method.
  • 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.

 

Never deploy the same template twice into a single resource group because this creates name conflicts. To deploy multiple instances into the same resource group, modify the template so all resources are renamed and all IP addresses are unique.

Creating an Instance using the Portal Marketplace

Complete the following steps to create an instance using the Portal Marketplace.

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.

 

  1. In the Azure portal, select the green '+' button in the top left of the screen.
  2. In the search bar, type "Arista" and select Enter.
    Figure 1. Type '"Arista"

     

  3. Select the Arista offer you are interested in.
    Figure 2. Arista selection

     

  4. Select Create.
    Figure 3. Select "Create"

     

  5. Fill out the required information and select OK.
    Figure 4. Required Information

     

  6. Configure the VNet and select OK.
    Figure 5. Configuring the VNet

     

  7. Configure the subnets and select OK.
    Figure 6. Configuring the Subnets

     

  8. Verify the information is correct and select OK.
    Figure 7. Verification
  9. Read the Terms and Conditions, then select Purchase.
    Figure 8. Terms and Conditions

Creating an Instance under Azure CLI 2.0

Complete the following steps to create an instance under Azure CLI 2.0.

  1. Install Azure CLI 2.0 ( https://docs.microsoft.com/en-us/cli/azure/install-azure-cli?view=azure-cli-latest).
  2. Run az login and follow the prompts to authorize the machine.
  3. Download the template and parameters files from the GitHub repository. https://github.com/Azure/azure-quickstart-templates.
  4. Open <prefix>-parameters.json:. Locate the ./single_line_json.sh user_data.txt script.
  5. Copy and paste the generated output into the customData value field of the JSON parameters file.
  6. Use the script as in the following example:
    #!/usr/bin/bash
    cat $1 | python -c 'import json, sys; print( json.dumps( sys.stdin.read() ) )'

     

  7. Use the template and parameters of the JSON files to launch a cloudEOS router instance in Azure using Azure CLI 2.0.
    $ az group create --name ExampleGroup --location "Central US"

     

    Note: You must use the same location as the storage account where the VHD image is uploaded.

     

    $ az group deployment create \
    --name ExampleDeployment \
    --resource-group ExampleGroup \
    --template-file <prefix>-template.json \
    --parameters @<prefix>-parameters.json

     

    Note: If you are using a newer version of the Azure CLI 2.0, you may encounter a parameter file parsing bug. To fix this, remove the @ symbol before the parameters filename.

     

Logging into Instance

To log into an instance, complete the following steps.

  1. Select the resource group containing your cloudEOS router deployment from the Resource groups list.
  2. Select the item publicIP.
    Figure 9. Selecting the PublicIP

     

  3. Locate the IP address and DNS name found on the Overview page.
    Figure 10. Locating the IP Address and DNS

     

    Note: If either of these fields is not populated, your instance will still be deployed. Refresh the page after a couple of minutes.

     

  4. Secure Shell (SSH) to your Virtual Machine (VM) using the IP address or Domain Name Server (DNS) name found in the previous step, using the credentials you gave when you initially setup the VM.
    bash# ssh This email address is being protected from spambots. You need JavaScript enabled to view it..1
    Password: *********

     

    Note: It may take between 5 to10 minutes for the instance to become reachable after the deployment starts. Refer to the section Troubleshooting Instance for additional information.

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
%EOS-STARTUP-CONFIG-START%
%EOS-STARTUP-CONFIG-END%
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

 

Note the following regarding the custom data.
  • 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.

  1. Select the resource group containing your cloudEOS router deployment from the Resource groups list.
  2. Select the item cloudEOS router.
    Figure 11. Select the cloudEOS router

     

  3. Note the status of the VM. It should be "Creating", "Starting", or "Running".
    Figure 12. Status of the VM

     

  4. Check the boot diagnostics for any error messages or warnings.
    Figure 13. Error Messages and Warnings

     

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

  1. Locate the cloudEOS router listing in the Google cloud Launcher, then select LAUNCH ON COMPUTE ENGINE.

     

     

  2. Fill out the relevant fields in the deployment screen, then select Deploy.

     

    Update zones, names, and other details as needed. Also, add a user name with a public SSH key for that user. You can also change the machine type depending on the performance requirements of the VM and add more than one NIC if needed.

     

    Note: When adding an SSH public key, paste it without extra spaces or new lines. For example, the public key looks similar to this.

     

  3. After deployment, you will find the information about your cloudEOS router instance on the post-deployment screen.

     

Logging into Arista cloudEOS

  1. From the post-deployment screen, select vm instance.

     

  2. Select MANAGE RESOURCE.

     

  3. Locate the External IP.

     

  4. Log into the instance using the credentials you entered during the deployment.
    “ssh -i <private_key_file> <username>@<external_ip>”.

     

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.

Note the following regarding the custom-data.
  • 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
%EOS-STARTUP-CONFIG-START%
%EOS-STARTUP-CONFIG-END%
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

x86-64 Server class CPU (32-bit CPUs are not supported) with
  • 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
Note: To ensure compatibility, upgrade the ESXi NIC drivers to the latest version provided by VMware.

 

VMware ESXi SR-IOV based deployment
  • 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.

 

KVM Minimum Server Requirements
  • 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.

 

KVM SR-IOV Based Deployment
  • Ethernet NICs must be SR-IOV capable
  • BIOS / System Firmware support for SR-IOV

Supported Topologies

The following scenarios are described in the Hypervisor Chapter.
  • 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

 

This section includes the following topics:

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.

 

Note: Arista support suggests using only the Vsphere Web client. The ESXi Web Client may have untested issues.

 

Note: Make sure the VMWare/ESXi Client used for OVA deployment supports the SHA256 hashing algorithm.

 

  1. From the vCenter Server WEB-UI navigator, select Deploy OVF template.

     

  2. Select the OVA file from the local machine.

     

  3. Select the name and location for WAN deployment.

     

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

     

  5. Verify the template details.

     

  6. Select Thick provision eager zeroed from the datastore.

     

  7. Select the default network.

     

  8. Complete the launch process.

     

  9. 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.

  1. Navigate to the ESXi host's Manage, then select the Hardware tab.

     

  2. Locate and select your PIC device/NIC.
  3. Use the Toggle passthrough or the Configure SR-IOV selection to activate the mode.

     

     

  4. Reboot the ESXi host so the configuration takes effect.
  5. After reboot, the NIC reflects the changes. For SR-IOV, new virtual function devices (VF) are created.

     

  6. Edit the VM and select Add other device, then select PIC Device to create the New PIC Device for the VM.

     

  7. Select the New PIC Device to use the SR-IOV VF or PIC Passthrough device.

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.

Hypervisor support
  • 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

Minimum requirements:
  • 2 vCPUs
  • 4GB Memory
  • 8G Free disk space

     

Maximum capacities
  • 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 XML definition format for networks is defined at https://libvirt.org/formatnetwork.html. These commands are similar to the VM, but with a prefix 'net-' :
  • 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>

Cut and paste the following XML template into a file (veos.xml) and customize the elements in bold below.
  • 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.

In this example,
  • 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.

 

Note: Arista recommends using Ethernet1 for cloudEOS router and Ethernet2 for LAN. However, any veos port can be used.

 

Figure 14. Linux Bridge and Virtio-based Deployment

 

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.

The following tasks are required to set up the host for SR-IOV.
  1. 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

     

  2. 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)

     

  3. 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

     

  4. 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 63

     

    To 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

     

  5. Use the rmmod ixgbe and modprobe ixgbe Linux commands to unload and reload the module.
  6. 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)

     

  7. 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

     

  8. 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>

     

  9. 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>

     

  10. 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.

 

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.
  • 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.
Figure 15. Linux SRIOV PCI Passthough-based Deployment

Setting Up the Host and Launching PCI Pass-through

Set up a networking device to use PCI pass-through.

When sharing resources is inefficient, or a virtualized router consumes packets before reaching the VM (veos), implementing PCI Pass-through for NIC provides dedicated and non-filtered network resources to the VM.
  1. 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)

     

  2. 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>

     

  3. 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 ~]$ 

     

  4. 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.

Setting up SR-IOV is initially more involved. Arista recommends starting with LinuxBridge.
  • 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)

This section discusses the cloudEOS router setup and configuration of the cloudEOS router Appliance. Refer to https://www.arista.com/en/qsg-ra-200-veos (Hardware QuickStart Guide) for any hardware-related configurations.

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

The cloudEOS router appliance has the following hardware configuration:
  • 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

  1. 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.
  2. 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.
  3. 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

cloudEOS router launcher script and cloudEOS router image are on the appliance under /data/tools/. Before launching cloudEOS routers, you can decide on how many cloudEOS router instances are needed and how should these be configured.

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 

 

The following observations are from the above example:
  • 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 

 

Besides launching/removing functionality, dca-200-veos-setup-vm.py script also provides a query command to print the current status of the running VMs. The output includes:
  • 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

 

For virtual console access there are two options:
  1. On the appliance virsh console <vm_name>
  2. 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

The following commands are used to find the bus number for the physical port:

[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

 

Command to get PCI bus information for all ethernet physical and virtual functions:

[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)

 

Command for VFs and Parent interface mapping (used for output above):

[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 script provides the below mechanisms helping with debugging:
  • cloudEOS routerlauncher error messages
  • cloudEOS routerlauncher query command
The below two examples are of error messages that a customer may see during creating an instances:

[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

 

Above error message points out the specified interface is already used by other VM. User can use a query command dca-200-veos-setup-vm.py -q to list all the interfaces used by the existing VMs and start using available interfaces to create new VMs. Refer to Launching/Removing/Query cloudEOS router section of the chapter for more query command information.

[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

When the appliance is shipped to customer, it is in a setup ready stage. Ideally customers need not worry about the scripts mentioned in this section. However, if there was some issues setting up the appliance, user may choose to run below test scripts under /data/imaging/ directory to verify the settings:
  • 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.

Below output from the script means appliance is properly setup:

[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

 

Note: /data/imaging/dca-200-veos-test.sh will bring host interfaces down and up again, which may impact running VMs traffic on the host.

 

/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.

Below output from the script means appliance NICs are in good stage:

[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']

 

Note:To make /data/imaging/dca-200-veos-test-nics.py test properly, appliance interfaces have to be connected in a way that 10GB1 connects to 10GB3, 10GB2 connects to 10GB4 and there’s no existing VMs on the appliance.

 

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

The 10G ethernet ports are tested using the following Arista 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.

The cloud high availability (cloud HA) feature adds support to make the cloudEOS router deployment more resilient to various failure scenarios in the cloud, such as:
  • 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.

Figure 17. cloud high availability network topology with router instances

 

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.

Note:For ease of discussion, we will use availability zone 1 and 2 to reference the high availability design in different clouds going forward.

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

 

The following describes configurations required for cloud HA on different types of clouds.

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

There are two authorization models that can be used in Azure: SDK Auth Credentials and Active Directory Credentials. SDK Auth Credentials are the recommended authorization model.
  • 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

 

To configure the BFD link between the HA pair of cloudEOS routers that is used to detect peer failure, the peer IP address and local BFD source interface must be provided. The following example configures Tunnel 2 as a single hop for 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

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:

  1. Open the Amazon VPC console and choose Endpoints in the navigation panel.
  2. Select Create Endpoint.
  3. Choose the AWS Services and select service name com.amazonaws.<your-region>.ec2.
  4. Choose the VPC and the subnets in each availability zone for the Interface VPC endpoints.
  5. Enable private DNS name and set security group accordingly.
  6. 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

There are two authorization models that can be used in Azure: SDK Auth Credentials and Active Directory Credentials. SDK Auth Credentials are the recommended authorization model.
  • 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.

Sample service account file:
{
"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.

Example
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

 

Global
  • cloud provider gcp
Interface (GCP)
  • project
  • service-account
cloud HA GCP Configuration
  • primary-gateway
  • backup-gateway
Show Commands
  • 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.

Command Mode

Global Configuration

Command Syntax

cloud provider gcp

Example
  • 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.

Command Mode

Global cloud Provider GCP Configuration

Command Syntax

project name

no project name

Parameter
  • name Specifies the selected GCP project name.
Example
  • 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.

Command Mode

Global cloud Provider GCP Configuration

Command Syntax

service-account file sa-file

no service-account file sa-file

Parameter
  • sa-file Specifies the path to the service account file.
Examples
  • 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.

Command Mode

cloud HA GCP Configuration Submode

Command Syntax

primary-gateway dest-prefix [tag rt-tag]

no primary-gateway dest-prefix [tag rt-tag]

Parameter
  • dest-prefix Specifies the destination IP prefix.
  • rt-tag Specifies the route tag.
Examples
  • 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.

Command Mode

cloud HA GCP Configuration Submode

Command Syntax

backup-gateway dest-prefix [tag rt-tag]

no backup-gateway dest-prefix [tag rt-tag]

Parameter
  • dest-prefix Specifies the destination IP prefix.
  • rt-tag Specifies the route tag.
Examples
  • 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.

Command Mode

EXEC

Command Syntax

show cloud high-availability routes

Example
  • 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.

Command Mode

EXEC

Command Syntax

show cloud provider gcp

Examples
  • 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

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.

Note:Supported only on AWS platform.

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.

Note:Supported only on Azure platform.

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.

Note:Supported on Azure platform only.

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.

Note:Supported on AWS platform only.

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.

Note: Enabled for Azure platform only.

Command Mode

Global Configuration

Command Syntax

cloud provider azure

Example

The following example places the cloud provider for Azure into the configuration mode.
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.

Note: Supported on Azure platform only.

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.

Note: Supported on AWS platform only.

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.

Note:Supported on AWS platform only.

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.

Note:Supported on AWS platform only.

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