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.
To manage Gateway pools, perform the following steps:
- In the Orchestrator UI, select the Gateway Management tab and go to Gateway Pools in the left navigation pane.
The Gateway Pools page appears.
Figure 1. Manage Gateway Pools 
Create New Gateway Pool
In addition to the default Gateway pool, you can create new Gateway pools and associate them with Enterprise Customers.
- In the New Gateway Pool dialog, configure the following details and select Create.
Figure 2. Create New Gateway Pool 
Table 2. New Gateway Pool Field Descriptions Field Description Name Enter a name for the new Gateway pool. Description Enter a description for the Gateway pool. Partner Gateway Hand Off This option determines the method to hand off the Gateways to Partners. Choose one of the following options from the drop-down list: - None – Select this option when Partner Gateway hand off is not required.
- Allow – Select this option when you want the Gateway pool to support a mix of both the Partner Gateways and Cloud Gateways.
- Only Partner Gateways – Select this option when Edges in the Enterprise should not be assigned with Cloud Gateways from the pool, and will only be assigned with the Gateways that are set for an individual Edge.
IP Version Choose one of the following address types with which the Gateway pool should be enabled: - IPv4 – Allows to add IPv4 only Gateways.
- IPv4 and IPv6 – Allows to add Gateways with IPv4 and IPv6 addresses.
Note: If you want to use Edges with IPv6 support, then choose IPv4 and IPv6.
- 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.
- In the Gateway Pools table, select the Gateway pool that you want to clone and select Clone. The New Gateway Pool dialog with the cloned settings appears.
Figure 3. Clone a Gateway Pool 
- 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:
- Configure the following details for the Gateway pool:
Figure 4. Configure Gateway Pools 
- In the Properties section, the existing Name, Description, Partner Gateway Hand Off details, and the Association Type are displayed. If required, you can modify these details.
- In the Gateways in Pool section, select Manage to add Gateways to the pool. The Assign Gateways to Gateway pool dialog appears.
- In the Assign Gateways to Gateway pool dialog, move the required Gateways from the Available pane to Assigned pane using the arrows and select Update.
Figure 5. Assign Gateways to Gateway pool 
- The Gateways assigned to the selected Gateway pool are displayed as follows.
Figure 6. Gateways in 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.
- For a new customer, see Create New Customer.
- For an existing customer, see Configure Customers.
- For a new Partner, see Create New Partner.
- For an existing Partner, see Configure 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.
To manage Gateways, perform the following steps:
- In the Orchestrator UI, select the Gateway Management tab and go to Gateways in the left navigation pane.
The Gateways page appears.
Figure 7. Manage Gateways 
To search a specific Gateway, enter a relevant search text in the Search box. For advanced search, select the filter icon next to the Search box to filter the results by specific criteria.
The Map Distribution section is used for displaying the Gateways on a map. You can select the + and - buttons to zoom in and zoom out the map, respectively.
The Gateways table displays the existing Gateways with the following details.
Table 3. Gateways Field Descriptions Field Description Name Name of the Gateway Status Reflects the success or failure of periodic heartbeats sent by mgd to the Orchestrator and does not indicate the status of the data and control plane. The following are the possible statuses: - Connected – Gateway is heart beating successfully to the Orchestrator.
- Degraded – Orchestrator has not heard from the Gateway for at least one minute.
- Offline – Orchestrator has not heard from the Gateway for at least two minutes.
CPU Average CPU utilization of all the cores in the system at the time of the last heartbeat. Memory Percentage usage of the physical memory by all processes in the system as reported by psutil.phymem_usageat the time of the last heartbeat. This is similar to estimating the percentage of memory usage using the free command.Edges Number of Edges connected to the Gateway at the time of the last heartbeat. Note: Select View next to the number of Edges, to view all the Edges assigned to the Gateway as well as their online/offline status on the Orchestrator. This option does not display the Edges that are actually connected to the Gateway.Service State The user-configured service state of the Gateway and whether it is eligible to be assigned to new Edges. IP Address The public IP address that public WAN links of an Edge use to connect to the Gateway. This IP address is used to uniquely identify the Gateway. If the Gateway is enabled to accommodate both IPv4 and IPv6 addresses, this column displays both the IP addresses. Location Location of the Gateway from GeoIP (by default) or as manually entered by the user. This is used for geographic assignment of the Gateway to Edges and should be verified.
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.
- In the New Gateway dialog, configure the following details:
Figure 8. Create New Gateway 
Table 4. New Gateway Field Descriptions Field Description Name Enter a name for the new Gateway. IPv4 Address Enter the IPv4 address of the Gateway. IPv6 Address Enter the IPv6 address of the Gateway. Service State Select the service state of the Gateway from the drop-down list. The following options are available: - In Service- The Gateway is connected and available.
- Out of Service- The Gateway is not connected.
- Quiesced- The Gateway service is quiesced or paused. Select this state for backup or maintenance purposes.
Note: The Quiesced and Out of Service states are only applicable for Cloud Gateway deployment.Gateway Pool Select the Gateway Pool from the drop-down list, to which the Gateway would be assigned. Authentication Mode Select the authentication mode of the Gateway from the following available options: - Certificate Not Required- Gateway uses a pre-shared key mode of authentication.
- Certificate Acquire- This option is selected by default and instructs the Gateway to acquire a certificate from the certificate authority of the Orchestrator, by generating a key pair and sending a certificate signing request to the Orchestrator. Once acquired, the Gateway uses the certificate for authentication to the Orchestrator and for establishment of VCMP tunnels.
Note: After acquiring the certificate, the option can be updated to Certificate Required.Note: With the Bastion Orchestrator feature enabled, the Gateways that are to be staged to Public Orchestrator should have the Authentication mode set to either Certificate Acquire or Certificate Required.
- Certificate Required- Gateway uses the PKI certificate. Operators can change the certificate renewal time window for Gateways using the system properties.
Contact Name Enter the name of the Site Contact. Contact Email Enter the Email ID of the Site Contact. Note:- Once you have created a Gateway, you cannot modify the IP addresses.
- Release 4.3.x and 4.4.x support Greenfield deployment of Gateways for IPv6. If you have upgraded a Gateway from a previous version earlier than 4.3.0, you cannot configure the upgraded Gateway with the IPv6 address.
- Release 4.5.0 supports both the Greenfield and Brownfield deployment of Gateways for IPv6. If you have upgraded a Gateway from a previous version earlier than 4.5.0, you can dynamically configure IPv6 address for the Gateway.
- IPv4/IPv6 dual-stack mode is not supported for Bastion Orchestrator configuration.
Once you create a new Gateway, you are redirected to the Configure Gateways page, where you can configure additional settings for the newly created Gateway.
To configure additional settings for the Gateway, see Configure Gateways.
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:
- In the Overview tab, you can configure the following details:
Figure 9. Configure Gateways Overview Screen 
Table 5. Configure Gateways Field Descriptions Option Description Properties Displays the existing Name and Description of the selected Gateway. If required, you can modify the information. You can also configure the Gateway Roles, as required:- Data Plane- Enables the Gateway to operate in the Data plane and is selected by default.
- Control Plane- Enables the Gateway to operate in the Control plane and is selected by default.
- Secure VPN Gateway- Select the option to use the Gateway to establish an IPsec tunnel to a Non SD-WAN Destination.
- Partner Gateway- Select the check box to allow the Gateway to be assigned as a Partner Gateway for Edges. If you select this option, configure the additional settings in the Partner Gateway (Advanced Handoff) Details section.
- CDE- Enables the Gateway to operate in Cardholder Data Environment (CDE) mode. Select this option to assign the Gateway for customers who require to transmit PCI traffic.
- Cloud-to-Cloud Interconnect- Select the option to enable cloud-to-cloud-interconnect (CCI) tunnels on the VeloCloud Gateways.
Note: This Gateway Role option is shown if the
session.options.enableZscalerCcisystem property is set to True. - Symantec Web Security Service: Enables the Gateway's Symantec Web Security Service capability. The Orchestrator assigns this Gateway to the Edge as WSS Primary Gateway or WSS Secondary Gateway.
Note: This assignment works only when the Gateway Pool's Partner Gateway Handoff is not set to Only.
Status You can configure the following details: - Status- Displays the status of the Gateway which reflects the success or failure of periodic heartbeats sent to the Orchestrator. The following are the available statuses:
- Connected- Gateway is heart beating successfully to the Orchestrator.
- Degraded- Orchestrator has not heard from the Gateway for at least one minute.
- Offline- Orchestrator has not heard from the Gateway for at least two minutes.
- Service State- Select the Service State of the Gateway from the following available options:
- In Service- The Gateway is connected, and it is available for Primary or secondary tunnel assignments. When the Service state of the Gateway is switched from the 'Out Of Service' to 'In Service' state, the Primary or Secondary assignments, Super Gateways, Edge-to-Edge routes are recalculated for each Enterprise using the Gateway.
- Pending Service- The Gateway is connected, and it is pending for tunnel assignments.
- Out of Service- The Gateway is not connected or not available for any assignments. All the existing assignments are removed.
- Quiesced- The Gateway service is quiesced or paused. No new tunnels or NSD sites can be added to the Gateway. However, the existing assignments would still remain in the Gateway. Select this state for backup or maintenance purposes.
Note: The Quiesced and Out of Service states are only applicable for Cloud Gateway deployment.
When the Service state is Quiesced, 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.
For additional information, see Quiesce Gateways.
Note: Self-service migration is not supported on Partner Gateways.
Connected Edges Displays the number of Edges connected to the Gateway. This option is displayed only when the Gateway is activated. Gateway Authentication Mode Select the authentication mode of the Gateway from the drop-down menu: - Certificate Deactivated- Gateway uses a pre-shared key mode of authentication. If you change the mode from Certificate Deactivated to:
- Certificate Acquire: Tunnels based on PSK mode are not impacted. Only tunnels with Gateways are impacted. These tunnels are reconnected based on certificate. All tunnels configured with PSK mode continue to stay active and no disruption is seen in the traffic.
- Certificate Required: The Orchestrator does not directly allow this change. You must first change the mode to Certificate Acquire, and then change it to Certificate Required. This helps avoiding heartbeat loss to the Orchestrator, when Edge is assigned a certificate.
- Certificate Acquire- This option is selected by default and instructs the Gateway to acquire a certificate from the certificate authority of the Orchestrator, by generating a key pair and sending a certificate signing request to the Orchestrator. Once acquired, the Gateway uses the certificate for authentication to the Orchestrator and for establishment of VCMP tunnels. If you change the mode from Certificate Acquire to:
- Certificate Deactivated: PSK based tunnels are not impacted. Tunnels with Gateways and all certificate-based tunnels are disconnected and reconnected based on PSK.
- Certificate Required: All peers configured with PSK mode are disconnected and cannot connect to the Hub. All current RSA tunnels stay active.
When the Hub is in Certificate Acquire mode, the tunnels based on the certificate are reestablished with new certificate. PSK based tunnels are not impacted.
Note: After acquiring the certificate, the option can be updated to Certificate Required. - Certificate Required- Gateway uses the PKI certificate. Operators can change the certificate renewal time window for Gateways using the system property
gateway.certificate.renewal.window. If you change the mode from Certificate Required to:- Certificate Deactivated: All peers with RSA tunnel are disconnected and cannot reconnect. All peers configured with PSK mode continue to stay active and no disruption is seen in the traffic.
- Certificate Acquire: All peers configured in PSK mode reconnect with Hub/Gateway. All current RSA tunnels stay active.
Note:- When Gateway certificate is revoked, the Gateway does not receive certificate revocation list (CRL) as it loses TLS connection immediately. Anyway, the Gateway is still operable.
- The current QuickSec design checks CRL time validity. The CRL time validity must match with current time of Edges for the CRL to have impact on new established connection. To implement this, ensure to update Orchestrator time properly to match with date and time of Edges.
IP Address Displays the public IP address that public WAN links of an Edge use to connect to the Gateway. This IP address is used to uniquely identify the Gateway. If you have configured the Gateway with both IPv4 and IPv6 addresses, this field displays both the IP addresses. If you have created IPv4 only Gateway or if there is an existing IPv4 Gateway upgraded from previous versions, you can enter the IPv6 address to support the dual stack. After you save the changes, the IPv6 address is not sent to the Edges immediately. You can trigger the rebalance operation to push the IPv6 address to the customer and the associated Edges manually or the IPv6 address is sent to the Edges during the next Control Plane update. Note: Adding IPv6 address is a one-time activity and once you save the changes, you cannot modify the IP addresses.CAUTION: An incorrectly configured IPv6 address, when pushed to Edges, might lead to failure of the IPv6 tunnelling to the IPv6 Gateway. In such cases, you need to deactivate the Gateway and create a new one to activate both the IPv4 and IPv6 addresses.Contact & Location Displays the existing contact details. If required, you can modify the information. NSD IP Portability Beginning with the 6.0 Orchestrator release, selecting this option will activate NSD IP Portability for the Gateway. Portable NSD IPs allow an Operators to move NSD configurations to different Gateways in the POP without requiring the customer to reconfigure their tunnels. When the NSD Portability check box is selected, the Orchestrator fetches the following data such as SASE PoP name, NSD Virtual IPv4 Address, and NSD Virtual IPv6 Prefix currently assigned to the Gateway from the Global Services Manager (GSM) and displays it. Select Refresh POP to retrieve the current and updated data. Note: For the "NSD Portability" feature to work as designed, the Operators must ensure that the Gateways are associated with the corresponding PoPs in GSM.Figure 10. Activate NSD IP Portability 
Important: There are two important caveats with NSD IP Portability:- NSD peers must operate as an IKE responder. In the past, some configurations would permit an initiator-only setup, but that will no longer function.
- Peers must allow NAT-T (NAT Traversal). The current implementation of NSD Portable IP uses NAT which is internal to the POP.
Syslog Settings Beginning with the 4.5 release, Gateways can export NAT information via a remote syslog server or via telegraf to the desired destination. Customer Usage Displays the usage details of different types of Gateways assigned to the customers. Pool Membership Displays the details of the Gateway pools to which the current Gateway is assigned. Partner Gateway (Advanced Handoff) Details This section is available only if you select the Partner Gateway check box. You can configure advanced handoff settings for the Partner Gateway. For additional information, see the Partner Gateway (Advanced Handoff) Details section below.
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:
|
Upgrade Orchestrator for Dual Stack Support
To upgrade Orchestrator to release 5.0.0 to support dual stack, perform the following:
- In the Operator Profiles page of the selected Profile, navigate to the Management Settings section and enter the IPv6 address configured in Orchestrator Shell.
Figure 11. Configure Dual Stack Support 
Configure IPv6 Address on Gateways
Ensure that the Orchestrator is running version 5.0.0 as described in Upgrade Orchestrator for Dual Stack Support.
You can provision a Gateway with both IPv4 and IPv6 addresses.
Partner Gateways
Partner Gateway can be configured with multiple subnets, each of which can be configured with a hand-off of NAT or VLAN. Each subnet can also be configured with a relative cost and whether the traffic should be encrypted or not.
The examples below illustrate two use cases for Partner Gateways configuration.
Gateway Configuration Use Case #1
In the following illustration, a Gateway is connected over VLAN/VRF mode to a VRF that has no access to the public Internet. However, the Partner Gateway must be able to contact the Orchestrator in the public cloud, and there must be a path to reach the cloud. The Gateway can selectively NAT certain traffic (such as the IP address of an Orchestrator, or the subnets used to reach public DNS servers) even though it is operating in VLAN/VRF mode.
- #1- Orchestrator traffic is routed using IP addresses to NAT.
- #2- Corporate Traffic is routed through subnets to VLAN/VRF.
Gateway Configuration Use Case #2
It is common for a Partner Gateway to tie into a corporate network, providing connectivity to legacy sites. This need can occur even when not all corporate sites have been converted to Aristanetwork. For this use case, it is necessary to specify traffic by subnet on the Partner Gateway. Each subnet can also be configured to encrypt network traffic.
The following illustration shows an example where only the traffic to legacy sites is encrypted. If the Gateway is already configured with a 0.0.0.0/0 subnet to allow all traffic (which is a common configuration), all that would be required is to add the private subnet for your legacy sites and mark it as encrypted.
- #1- Subnet (e.g., 10.0.0.0/8) defined for Legacy Sites and marked for encryption. Traffic is transmitted between Edge and Gateway over the IPsec tunnel.
- #2- Remaining traffic is sent unencrypted to the Edge, and then to its final destination.
- For an IPsec tunnel via Partner Gateway, the VCMP tunnel failure causes the existing flows to timeout. The expected behavior for existing flows is to remain on the current path. Any new flow will begin to go (direct) causing the tunnel to remain down.
- Use application map flags
mustUseGatewayanddropIfPartnerGatewayDownto force or drop traffic through the Gateway until the path is restored. If these flags are not active, a flow flush is required once tunnel path is restored.
Partner Gateway Resiliency
The Partner Gateway provides resiliency by detecting failures and failing over to an alternate Partner Gateway. This includes the ability of a Partner Gateway to detect failure conditions and for the surrounding infrastructure to detect failures of the Gateway itself.
Consider the following Gateway topology:
| Failure Zone | Component | Description |
|---|---|---|
| 1 | Provider Edge | The Provider Edge is one instance in which failure can be detected either from the Provider Edge router pinging the Gateway, or from the Gateway to the Provider Edge router. |
| 2 | Call Controller | The Gateway should be able to ping the Provider Edge router or Call Controller to verify connectivity. |
| 3 | WAN | The Gateway should have a stateful ping responder that responds only if the WAN zone is available. |
The Partner Gateway also supports configurable route costs to allow for more flexible failure scenarios. Finally, there is an additional hand-off type required where neither NAT nor VLAN tags are applied to the packets and they are simply passed through to the Provider Edge router.
ICMP Failover Probes
This section discusses ICMP failover probes.
In order to address a failure in zones #1 or #2 of the Gateway topology diagram, the Gateway supports the optional ability to send failover probes. These probes will ping a single destination IP address at the specified frequency. If the threshold for successive missed ping replies is exceeded, the VeloCloud Gateway will mark the Gateway’s routes as unreachable. While the routes are marked as unreachable due to this probe failure state, probes continue to be sent. If the same threshold is exceeded for successive successful pings replies, the Gateway will mark the routes as reachable again.
Example Scenario
For example, consider the case in which a user has configured a frequency of two seconds and a threshold of three.
- VeloCloud Edges connect to the primary Gateway. The primary Gateway marks routes as reachable.
- The Primary Gateway fails to receive a reply for three successive probes (~6 seconds).
- The Primary Gateway marks routes as unreachable and communicates this to all connected Edges.
- Edges begin routing Gateway traffic via the alternate Gateway.
- Connectivity is restored and the primary Gateway receives three successive replies from probes.
- The Primary Gateway marks routes as reachable and communicates this to all connected Edges.
- Edges route traffic back through the primary Gateway.
This could be used in failure scenario #1 to ping an IP address on the Provider Edge router itself. This could be used in failure scenario #2 to ping the actual Call Controller.
Stateful Ping Responder
To address a failure in zone #2 or #3 of the Partner Gateway topology diagram, the Gateway supports an optional stateful ping responder. This allows the configuration of a virtual IP address (which must be different from the interface IP address) within the Gateway that will, based on configuration, either respond to pings always ( Gateway service is running) or conditionally based on WAN connectivity (the Gateway has VPN tunnels connected).
This can be used in failure scenario #1 by having the Provider Edge router ping the ping responder, as the Gateway becoming unreachable would cause the IP SLA on the Provider Edge router to fail. This could also be used in failure scenario #3 by having the Gateway only respond if VPN tunnels are connected- this is similar to the behavior with BGP (no clients connected means no client routes).
The Partner Gateway will respond back to the Provider Edge (PE) router ICMP request based on the IP SLA configured in the PE router. The Stateful Ping Responder PE router should be configured as shown below with proper VLAN tag information.
!IP-SLA configuration to send ICMP request to gateway virtual IP ip sla 1 icmp-echo 192.168.10.10 source-ip 192.168.10.1 vrf CUSTOMER1 threshold 1000 timeout 1000 frequency 2 ip sla schedule 1 life forever start-time now !tracking the IP SLA for its reachability track 1 ip sla 1 reachability !all the routes will reachable only when SLA probe succeeds ip route vrf CUSTOMER1 0.0.0.0 0.0.0.0 192.168.11.101 track 1 ip route vrf CUSTOMER2 0.0.0.0 0.0.0.0 192.168.12.101 track 1 ip route vrf CUSTOMER1 10.0.0.0 255.0.0.0 192.168.10.10 track 1 ip route vrf CUSTOMER2 10.0.0.0 255.0.0.0 192.168.10.10 track 1 ip route vrf CUSTOMER1 192.168.100.0 255.255.255.0 192.168.10.10 track 1Caveats When Using NAT Hand-off Mode
- For VLAN hand-off mode, the Partner Gateway can listen on any IP if it is reachable to the PE router (including its interface IP). For NAT hand-off mode, the Partner Gateway will not respond if the ICMP request comes to its own interface (WAN) IP address.
- Reverse flow is not supported in the NAT hand-off mode.
Active/Backup Subnets
This section describes how to configure active and backup subnets for a Partner Gateway.
Subnets on a Partner Gateway
Subnets configured on a Partner Gateway are input as subnets and optional descriptions. A Cost field is included to allow for weighting between routes. Lower-cost routes are preferred over higher-cost routes. The following figure shows Cost settings per subnet.
Monitor Gateways
You can monitor the status and network usage data of Gateways available in the Operator portal.
To monitor the Gateways:
- The Gateways page displays the list of available Gateways.
Figure 18. Gateways Screen 
- Select the link to a Gateway to view the details of the selected Gateway.
Figure 19. View Gateway Overview 
The Overview tab displays the properties, status, location, customer usage, and Gateway Pool of the selected Gateway.
Note: In the Overview tab, you can modify the Name and Description of the selected Gateway, and choose a different Service State. To configure the other options, navigate to the Gateways page in the Operator portal. - Select the Monitor tab to view the usage details of the selected Gateways.
Figure 20. Monitor Network Usage of Gateways 
At the top of the page, you can choose a specific time period to view the details of the Gateway for the selected duration.
The page displays graphical representation of usage details of the following parameters for the period of selected time duration, along with the minimum, maximum, and average values.- CPU Percentage – Percentage of usage of CPU.
- Memory Usage – Percentage of usage of memory.
- Flow Counts – Count of traffic flow.
- Over Capacity Drops – Total number of packets dropped due to over capacity since the last sync interval. Occasional drops are expected, usually caused by a large burst of traffic. However, a consistent increase in drops usually indicates a Gateway capacity issue.
- Tunnel Count – Count of tunnel sessions for both the IPv4 and IPv6 addresses.
Hover the mouse on the graphs to view additional details.
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.
Quiesce Gateways
When you choose to decommission a Gateway, you must change the Gateway to Quiesced state so that no new tunnels or NSDs can be configured on the Gateway. Ensure that you have Operator Super User role to quiesce Gateways.
Before you quiesce the existing Gateway, ensure that you create a new Gateway as a replacement. Assign the new Gateway with the same role and attach it to the same Gateway pool as the existing Gateway. For instructions, see the “Configure Gateways” section in the VeloCloud SD-WAN Operator Guide. Also, review the Limitations of VeloCloud Gateway Migration before you proceed with quiescing the Gateway.
To quiesce the Gateway and enable self-service migration:
- Select the link of the Gateway that you want to quiesce. The details of the Gateway appears in the Overview tab.
Figure 23. Quiesce Gateways 
Send decommission notification to Partners and direct customers who are impacted. The notification email provides the migration deadline and detailed instructions on how to migrate the Edges and NSDs from the quiesced Gateway to the new Gateway.
Decommission Quiesced Gateways
Before you decommission the quiesced Gateways, ensure that there are no Edges or NSDs connected to the Gateway.
In case there are Partners or direct customers who have not yet migrated from the quiesced Gateways, follow-up with them to ensure that they migrate from the quiesced Gateway. Verify that the quiesced Gateway is empty and then decommission it.
To decommission a quiesced Gateway:
- Select the link of the Gateway that you want to decommission. The details of the Gateway appears in the Overview tab.
Figure 24. Decommission Quiesced Gateways 
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:
- In the Request Diagnostic Bundle dialog, configure the following details and select Submit.
Figure 25. Request Diagnostic Bundle Dialog 
Table 8. Request Diagnostic Bundle Field Descriptions Field Description Target Select the target Gateway from the drop-down list. The data is collected from the selected Gateway. Reason for Generation Optionally, you can enter your reason for generating the bundle. Core Limit Select a Core Limit value from the drop-down, which is used to reduce the size of the uploaded bundle when the Internet connectivity is experiencing issues. The Diagnostic Bundles page displays the details of the bundle being generated, along with the status.
To search a specific diagnostic bundle, enter a relevant search text in the Search box. For advanced search, select the filter icon next to the Search box to filter the results by specific criteria.
Figure 26. Diagnostic Bundles Screen 
- 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 27. Update Cleanup Date Dialog 
- 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:
- In the Request PCAP Bundle dialog, configure the following details and select Generate.
Figure 28. Request PCAP Bundle Dialog 
Table 9. Request PCAP Bundle Field Descriptions Field Description Target Choose the target Gateway from the drop-down list. The packets are collected from the selected Gateway. Connectivity Choose an Interface or an Edge ID from the drop-down list. The packets are collected on the selected Interface or Edge associated to the Gateway. Duration Choose the time in seconds. The packets are collected for the selected duration. The default value is 5 seconds. Reason for Generation Optionally, you can enter your reason for generating the bundle. PCAP Filters You can define PCAP filters by which you want to control the PCAP data to be generated by choosing the following options: - IP1- Enter an IPv4 address, or IPv6 address, or Subnet mask.
- IP2- Enter an IPv4 address, or IPv6 address, or Subnet mask.
- IP1:Port1- Enter a Port ID associated with IP1.
- IP2:Port2- Enter a Port ID associated with IP2.
- Protocol- Select a protocol from the list.
Note: If you choose to use the PCAP filtering capability then you must define at least one filter.Advanced Filters You can define free form filters by which you want to control the PCAP data to be generated. The Diagnostic Bundles page displays the details of the PCAP bundle being generated, along with the status.