◄
►

VeloCloud Gateway Migration

The VeloCloud Orchestrator offers self-service migration functionality, enabling migration from an existing Gateway to a new Gateway without requiring the Operator’s support.

The following scenarios require Gateway migration:
  • Achieving operational efficiency.
  • Decommissioning old Gateways.

Gateway configurations define specific roles. For example, a Gateway with a data plane role is used to forward data plane traffic from source to destination. Similarly, a Gateway with a Control Plane role is referred to as a Super Gateway for assignment to an Enterprise. The Super Gateway establishes connections with all Edges within the Enterprise. Additionally, a Gateway with the Secure Virtual Private Network (VPN) role establishes an Internet Protocol Security (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, refer to the Configure Gateways section in the VeloCloud SD-WAN Operator Guide.

The following figure illustrates the migration process of the Secure VPN Gateway:
Figure 1. Secure VPN Gateway Migration

In this example, a VeloCloud Edge connects to an NSD through a Secure VPN Gateway, VCG1. The Orchestrator currently flags VCG1 for decommissioning. Before decommissioning, the administrator creates a new Gateway, VCG2, and assigns VCG2 the same role and attaches it to the same Gateway pool as VCG1, allowing VCG2 to replace the original Gateway. The administrator then changes the service state of VCG1 to "Quiesced," which prevents the system from adding new tunnels or NSDs to VCG1. However, VCG1 retains its existing assignments. After the administrator updates the VCG2 IP address configuration in the NSD, VCG2 establishes an IPsec tunnel to the NSD and switches the traffic from VCG1 to VCG2. The administrator decommissions VCG1 after confirming it contains no remaining sessions.

Following is the high-level workflow of Secure VPN Gateway migration based on the User roles:
Figure 2. Secure VPN Gateway Migration Workflow

Limitations of VeloCloud Gateway Migration

Keep in mind the following limitations when users migrate their Gateways:
  • Partner Gateways do not support self-service migration.
  • 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 an NSD utilizes redundant Gateways and the administrator quiesces one Gateway, the remaining redundant Gateway cannot replace 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.
  • When a customer deploys an NSD via Gateway with Border Gateway Protocol (BGP) enabled, the Self-Service Gateway Migration feature does not migrate BGP configurations to the new Gateway. Consequently, the system drops all BGP sessions after the migration completes.

    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 Service Settings > Gateway Migration on the Orchestrator and initiates the Gateway Migration process to move their NSD to a different Gateway. Post-migration, the new Gateway fails to populate the BGP Local ASN and Router ID information, which prevents NSD BGP sessions from establishing and causes the loss of all routes. Traffic remains disrupted until the administrator 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. Before the migration, the user should document all BGP settings and manually reconfigure these settings after the migration to minimize the impact on customer users.

Migrate Quiesced Gateways

Operators send notification emails about the Gateway migration to Administrators with Super User privileges. Plan the migration based on the notification email that users receive from their Operator.

Before you begin: Before migrating Edges and NSDs (if configured) from the quiesced Gateway to the new Gateway, the administrator must schedule a maintenance window, as the migration may disrupt traffic.

To avoid any service disruption, ensure that users 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:

  1. In the SD-WAN service of the Enterprise portal, go to Service Settings > Gateway Migration .
    The list of quiesced Gateways appears.
    Figure 3. Quiesced Gateways
  2. Select Start for the quiesced Gateway from which users want to migrate to the new Gateway.
    Note: Step 3 and Step 4 are only applicable if users have the NSDs configured from the quiesced Gateway. If the configuration contains no NSDs, proceed to Step 5 to rebalance the cloud Gateways and Edges that connect to the quiesced Gateway.
  3. Configure the required settings for all NSDs that route through the quiesced Gateway.
    Figure 4. Configure NSD Site(s)
    1. Select the View IKE IPsec link to view a sample configuration for the NSD. Copy the template and customize it to suit user's deployment.
    2. Add the IP address of the SD-WAN Gateway (new Gateway IP) to each NSD configured for the quiesced Gateway. For example, if users have configured an NSD for AWS, users must add the IP address of the new Gateway to the NSD configuration in the AWS instance.
    3. After making the configuration changes to all the NSDs, select The listed NSD site(s) have been configured checkbox, then select Next.
    Note: The Configure NSD Site(s) option is not available for NSDs configured automatically, and for Gateways with Data Plane role that are not attached to any NSDs.
  4. Select each NSD then select Switch Gateway to switch the traffic from the quiesced Gateway to the new Gateway.
    Figure 5. Switch Gateway
    1. In the Switch Gateways pop-up window, select The NSD site has been configured checkbox to confirm that users have made the required changes to the remote-end NSD configuration.
      Figure 6. Switch Gateways
      Note: This confirmation does not apply to NSDs configured automatically.
    2. Select Switch Gateway.

      It may take a few minutes to verify the tunnel status. The IP address of the quiesced Gateway is replaced with the IP address of the new Gateway, allowing traffic to switch to the new Gateway. The Migration Status changes to NSD Tunnels are up and running as shown in the following screenshot. If the Switch Gateway action fails, see What to do When Gateway Action Fails.

      Figure 7. Migration Status
    3. Select Next.
      Note: The Switch Gateway option is not available for Gateways with Data Plane role that are not attached to any NSDs.
    4. Rebalance the Cloud Gateways (Primary, Secondary, or Super Gateways) for all relevant Edges to reassign them from the quiesced Gateway to the new Gateway. Users can also rebalance Gateways from the Configure > Edges page.
      Figure 8. Rebalance Cloud Gateways
      When rebalancing Super Gateways, all Edges connected to the quiesced Gateway get rebalanced. Rebalancing of selected Edges is not allowed.
      Figure 9. Rebalance All Edges

       

      Figure 10. Rebalance Selected Edges
      Select the Edges that connect to the quiesced Gateway, then select Rebalance Gateway to reassign them to the new Gateway.
      Figure 11. Rebalance Gateways
  5. Select Rebalance Gateway to complete the Gateway migration.
    The Edges connected to the quiesced Gateway get migrated to the new Gateway.
    Figure 12. Rebalance Cloud Gateways
  6. Select Finish.
    Go to the Gateway Migration page then select Review to review the migration steps, if necessary.
    Figure 13. Gateway Migration

    The migrated Gateways remain in this page until the Migration Deadline assigned for the quiesced Gateway. After the Migration Deadline, users can view the history of migration events in the Monitor > Events page.

    Figure 14. Monitor Events

What to do When Gateway Action Fails

During the Gateway migration, when the Switch Gateway action for a Non SD-WAN Destination (NSD) fails, perform the following steps to troubleshoot the issue:
  1. In the SD-WAN service of the Enterprise portal, go to the Gateway Migration page. For instructions to navigate to this page, see Migrate Quiesced Gateways.
  2. Under the Switch Gateways step of the Migration Wizard, select the NSD for which the Switch Gateway action failed, then select Retry Tunnel Verification.

    The tunnel status is verified again to see if the Migration Status changes to NSD Tunnels are up and running.

    If the Migration Status does not change and the Switch Gateway action fails again for the NSD, select the NSD, then select Undo Switch Gateways.

    The Orchestrator reverts all NSD configuration changes to the original settings.

  3. Select Switch Gateways again to replace the IP address of the quiesced Gateway with that of the new Gateway and thereby switch the traffic to the new Gateway.
  4. Rebalance the Gateway and complete the migration.
Select View Events on the Gateway Migration page to view the history of migration events on the Monitor > Events page.