Manage Gateway Pools and Gateways
Arista network consists of multiple service Gateways deployed at top tier network and cloud data centers. The Gateway provides the advantage of cloud-delivered services and optimized paths to all applications, branches, and data centers. Service providers can also deploy their own Partner Gateways in their private cloud infrastructure.
Manage Gateway Pools
A Gateway Pool is a group of Gateways.
Gateways can be organized into pools that are then assigned to a network. An unpopulated default Gateway pool is available after you install Orchestrator. If required, you can create additional Gateway pools.
The New Gateway Pool and Download options are available only for Partners with Gateway management access activated. If the Gateway management access is deactivated for a Partner, then the Partner will have only read-only permission for the configured Gateway pools. To request Gateway Management access, Partners must contact the Operator Super user.
To manage Gateway pools, perform the following steps:
Create New Gateway Pool
In addition to the default Gateway pool, you can create new Gateway pools and associate them with Enterprise Customers.
Configure the Gateway pool by adding Gateways to the pool. See Configure Gateway Pools.
Clone a Gateway Pool
You can clone the configurations from an existing Gateway pool and create a new Gateway pool with the cloned settings.
Configure the Gateway pool by adding Gateways to the pool. See Configure Gateway Pools.
Configure Gateway Pools
After creating a Gateway pool, you can add Gateways to the pool and associate the pool to an Enterprise Customer.
Whenever you create a new Gateway pool or clone a pool, you are redirected to the Gateway Pool Overview page to configure the properties of the pool.
To configure an existing Gateway pool:
You can associate the Gateway pool to a Partner or an Enterprise Customer. The Edges available in the Enterprise are connected to the Gateways available in the pool.
Refer to the following links to associate the Gateway pool:
- For a new Partner customer, see Create New Partner Customer.
- For an existing Partner customer, see Configure Partner Customers.
- For a new Partner, see Add New User.
- For an existing Partner, see User Management - Partner.
Manage Gateways
VeloCloud Gateways are a distributed network of gateways, deployed around the world or on-premises at service providers, provide scalability, redundancy and on-demand flexibility. The Gateways optimize data paths to all applications, branches, and data centers along with the ability to deliver network services to and from the cloud.
By default, the Gateways named as gateway-1 and gateway-2 are available when you install Orchestrator. If required, you can create additional Gateways.
Partner Super user and Admin with Gateway management access activated can create, manage, and delete Gateways created by a Partner or Partner managed Gateways created by an Operator. The Partner IT support users can only view the configured Gateways.
To manage Gateways, perform the following steps:
Create New Gateway
In addition to the default Gateways, you can create Gateways and associate them with Enterprise Customers.
To create a Gateway, perform the following steps.
Configure Gateways
When you create a new Gateway, you are automatically redirected to the Configure Gateways page, where you can configure the properties and other additional settings for the Gateway.
To configure an existing Gateway:
Partner Gateway (Advanced Handoff) Details
You can configure the following advanced handoff settings for the Partner Gateway:
| Option | Description |
|---|---|
| Static Routes | Subnets– Specify the subnets or routes that the Gateway should advertise to the Edge. This is global per Gateway and applies to ALL customers. With BGP, this section is used only if there is a shared subnet that all customers need to access and if NAT handoff is required.
Remove the unused subnets from the Static Route list if you do not have any subnets that you need to advertise to the Edge and have the handoff of type NAT. You can select the IPv4 or IPv6 tab to configure the corresponding address type for the Subnets. |
|
| Subnets | Enter the IPv4 or IPv6 address of the Static Route Subnet that the Gateway should advertise to the Edge. |
| Cost | Enter the cost to apply weightage on the routes. The range is from 0 to 255. |
| Encrypt | Select the check box to encrypt the traffic between Edge and Gateway. |
| Hand off | Select the handoff type as VLAN or NAT. |
| Description | Optionally, enter a descriptive text for the static route. |
| ICMP Probes and Ping Responders Settings | |
| ICMP Failover Probe– The Gateway uses ICMP probe to check for the reachability of a particular IP address and notifies the Edge to failover to the secondary Gateway if the IP address is not reachable. This option supports only IPv4 addresses. | |
| VLAN Tagging | Select the VLAN tag from the drop-down list to apply to the ICMP probe packets. The following are the available options:
|
| Destination IP address | Enter the IP address to be pinged. |
| Frequency | Enter the time interval, in seconds, to send the ping request. The range is from 1 to 60 seconds. |
| Threshold | Enter the number of times the ping replies can be missed to mark the routes as unreachable. The range is from 1 to 10. |
| ICMP Responder- Allows the Gateway to respond to the ICMP probe from the next hop router when the tunnels are up. This option supports only IPv4 addresses. | |
| IP address | Enter the virtual IP address that will respond to the ping requests. |
| Mode | Select one of the following modes from the drop-down list:
|
Monitor Gateways
You can monitor the status and network usage data of Gateways available in the Partner portal of the Orchestrator.
To monitor the Gateways:
SD-WAN Gateway Migration
VeloCloud Orchestrator provides a self-service migration functionality that allows you to migrate from your existing Gateway to a new Gateway without your Operator’s support.
- Achieve operational efficiency.
- Decommission old Gateways.
Gateways are configured with specific roles. For example, a Gateway with data plane role is used to forward data plane traffic from source to destination. Similarly, a Gateway with Control Plane role is called a Super Gateway and is assigned to an Enterprise. Edges within the Enterprise are connected to the Super Gateway. Also, there is a Gateway with Secure VPN role that is used to establish an IPSec tunnel to a Non SD-WAN destination (NSD). The migration steps may vary based on the role configured for the Gateway. For additional information about the Gateway roles, see the “Configure Gateways” section in the Arista VeloCloud SD-WAN Operator Guide.
The following figure illustrates the migration process of the Secure VPN Gateway:

In this example, an SD-WAN Edge is connected to an NSD through a Secure VPN Gateway, VCG1. The VCG1 Gateway is planned to be decommissioned. Before decommissioning, a new Gateway, VCG2 is created. It is assigned with the same role and attached to the same Gateway pool as VCG1 so that VCG2 can be considered as a replacement to VCG1. The service state of VCG1 is changed to Quiesced. No new tunnels or NSDs can be added to VCG1. However, the existing assignments remain in VCG1. Configuration changes with respect to the IP address of VCG2 are made in the NSD, an IPSec tunnel is established between VCG2 and NSD, and the traffic is switched from VCG1 to VCG2. After confirming that VCG1 is empty, it is decommissioned.
Following is the high-level workflow of Secure VPN Gateway migration based on the User roles:

Limitations of VeloCloud Gateway Migration
- Self-service migration is not supported on Partner Gateways.
- There will be a minimum service disruption based on the time taken to switch Non SD-WAN Destinations (NSDs) from the quiesced Gateway to the new Gateway and to rebalance the Edges connected to the quiesced Gateway.
- If the NSD is configured with redundant Gateways and one of the Gateways is quiesced, the redundant Gateway cannot be the replacement Gateway for the quiesced Gateway.
- During self-service migration of a quiesced Gateway, the replacement Gateway must have the same Gateway Authentication mode as the quiesced Gateway.
- For a customer deploying a NSD via Gateway where BGP is configured on the NSD, if the customer migrates the NSD to a different Gateway using the Self-Service Gateway Migration feature on the Orchestrator, the BGP configurations are not migrated and all BGP sessions are dropped post-migration.
In this scenario, the existing Gateway assigned to the NSD is in a quiesced state and requires migration to another Gateway. The customer then navigates to on the Orchestrator and initiates the Gateway Migration process to move their NSD to another Gateway. Post-migration, the BGP Local ASN & Router ID information is not populated on the new Gateway and results in NSD BGP sessions not coming up with all routes being lost and traffic using those routes is disrupted until the user manually recreates all BGP settings.
This is a Day 1 issue and while the Gateway Migration feature accounts for many critical NSD settings, the NSD's BGP settings that are not accounted for, and their loss post-migration is an expected behavior.
Workaround: The migration of a Gateway should be done in a maintenance window only. Prior to the migration, the user should document all BGP settings and be prepared to manually reconfigure these settings post-migration to minimize impact to customer users.
Migrate Quiesced Gateways
Operators send notification emails about Gateway migration to Administrators with Super User privileges. Plan your migration based on the notification email that you receive from your Operator.
Before you migrate the Edges and NSDs (if configured) from the quiesced Gateway to the new Gateway, ensure that you schedule a maintenance window as traffic may be disrupted during migration.
To avoid any service disruption, ensure that you migrate to the new Gateway within the Migration Deadline mentioned in the notification email.
To migrate from a quiesced Gateway to a new Gateway, perform the following steps:
What to do When Switch Gateway Action Fails
During the Gateway migration, when the Switch Gateway action for an Non SD-WAN Destination (NSD) fails, perform the following steps to troubleshoot the issue:
Select View Events on the Gateway Migration page to view the history of migration events in the page.
Diagnostic Bundles for Gateways
Request Diagnostic Bundles for Gateways
Diagnostic bundles allow users to collect all the configuration files and log files from a specific VeloCloud Gateway into a consolidated zipped file. The data available in the diagnostic bundles can be used for troubleshooting the Gateways.
To generate a new Diagnostic bundle:
- Download Diagnostic Bundle- You can download the generated Diagnostic bundles to troubleshoot an Edge. To download a generated bundle, select the link next to Complete in the Request Status column or select the bundle and select Download Bundle. The bundle is downloaded as a ZIP file. You can send the downloaded bundle to a Arista Support representative for debugging the data.
- Delete Diagnostic Bundle- The completed bundles get deleted automatically on the date displayed in the Cleanup Date column. You can select the link to the Cleanup Date or choose the bundle and select to modify the Date.
Figure 30. Delete Diagnostic Bundle 
In the Update Cleanup Date dialog, choose the date on which the selected Bundle would be deleted.
If you want to retain the Bundle, select the Keep Forever check box, so that the Bundle does not get deleted automatically.
To delete a bundle manually, select the bundle and select Delete.
Request Packet Capture Bundle for Gateways
The Packet Capture bundle collects the packets data of a network. These files are used in analyzing the network characteristics. You can use the data for debugging the network traffic and determining network status.
To generate a PCAP bundle:




























