VMware SD-WAN Gateway Maintenance FAQs
Article ID: 330720
Updated On:
Products
Issue/Introduction
Resolution
VMware SD-WAN Key concepts
Q: What is a Gateway?
A: VMware SD-WAN Gateways are a distributed network of gateways, deployed in VMware or Service Provider’s Points of Presence (PoPs) around the world. Gateways are configured with 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 called a Super Gateway and is assigned to an Enterprise. Edges within the Enterprise are connected to the Super Gateway.
Additionally, there is a Gateway with a Secure VPN role that is used to establish an IPsec tunnel to a Non-SD-WAN destination (NSD), please refer to Configure Non-SD-WAN Destinations via Gateway for added details about this configuration.
VMware SD-WAN Gateways have an IP address (IPv4 and/or IPv6) assigned that uniquely identifies them, and this IP address is used for receiving incoming IPsec tunnels as well as sourcing outbound internet traffic.
Note: VMware does not guarantee that the Gateway IP address will not change.
Q: What is a Point of Presence (POP)?
A: VMware SD-WAN Gateways are deployed in VMware data center locations. In some locations, the Gateways are strategically deployed and hosted on public clouds. In the case of public cloud deployments, VMware has chosen locations and providers that are well-peered locally to maintain an optimal connection to Cloud Service Provider (CSP) services.
In addition to the existing VMware SD-WAN Gateways, VMware is also adding VMware Edge PoPs hosting VMware SD-WAN Gateways, VMware Secure Access, and VMware Cloud Web Security services.
Note: The Orchestrator (VCO) will have one or more Gateways in each POP, allocated based on VMware’s capacity planning.
Q: What is a Gateway pool?
A: A Gateway Pool is a group of Gateways that can be assigned to an Enterprise. Typically, hosted SD-WAN customers will be assigned a pool called Production Pool, which contains all the VMware-hosted Gateways assigned to the Orchestrator.
Q: What is Gateway rebalancing?
A: A Gateway rebalance can be triggered to move SD-WAN Edges to a different Gateway. When triggering a Gateway rebalance, the Orchestrator will attempt to equally distribute the load within Gateways in a pool. Though rebalancing is not impactful, these rebalancing events typically take place during regularly scheduled maintenance windows out of an abundance of caution.
Note: Please read the SD-WAN Gateway Migration FAQs, Important Caveats, and Allow List Limitation below for the full scope.
Q: What is a Gateway in Quiesced state?
A: The service state of a Gateway is changed to Quiesced for maintenance purposes. When a Gateway is moved to this state, no new tunnels or NSDs can be configured on the Quiesced Gateway.
Q: What is a Gateway in Out of Service state?
A: The service state of a Gateway is changed to Out of Service once this Gateway has been decommissioned. When a gateway is changed to Out of Service all traffic flow through that gateway is blocked, Edges or NSD tunnels must not be connected to Gateways in this state. Gateways are moved to this state as the last step in the Gateway migration process.
Note: Please read the SD-WAN Gateway Migration FAQs below for the full scope.
Q: What is VMware SD-WAN Gateway Capacity Planning?
A: When a Gateway is nearing (doing trend analysis) or exceeding (based on alarms) capacity, the VMware Edge Operations team and VMware Support team work together to address the situation. VMware Edge Operations team adds capacity as needed for a given VCO/POP to ensure that Edge, tunnel, flow, NAT entry, and throughput all have sufficient headroom to handle future capacity events.
A Gateway rebalance can be triggered to move customer SD-WAN Edges from one Gateway to another based on VMware’s capacity planning thresholds. In case of a planned event due to POP changes, customers will be notified with a preemptive Maintenance Incident Notification System (MINS) email. A Gateway rebalance can also be triggered in case of urgent customer-impacting issues; a MINS notification will be sent to notify of the event at the time of change.
Important Caveats
- A brief service outage is only expected when migrating Secure VPN Gateways authenticated or bound to a specific IP address, as there will be an IPsec tunnel flap (Between the Secure VPN Gateway and the NSD via Gateway peer). The source IP address of the IPsec tunnel endpoint will change to reflect the new Secure VPN Gateway IP address.
- There is no impact expected during the migration for FQDN authenticated IPsec tunnels. Redundant Secure VPN Gateways are supported and can be added to the NSD via Gateway configuration. VMware highly recommends using redundant Gateways as a backup for the VPN (IPsec) setup, especially when using IP addresses instead of FQDN.
- During the Gateway Migration, the new Gateway will use a new IP address to source Internet-bound Multipath traffic. Also, the SD-WAN Edges will use this new IP address as a destination for VCMP traffic (Tunnel between SD-WAN Edge and Gateway).
Allow List Limitation
VMware does not recommend a strict allow list for a single Gateway IP address on branches, data centers, or SaaS (Software as a Service) providers. Allowing traffic for a single Gateway IP address will result in a service outage after Gateway Rebalancing and Gateway Migration, because the new Gateway will have a different IP address. Customers should avoid this configuration for a successful transition.
If you are already using an allow list during the SASE Gateway Migration, you must add the following IP address ranges to the existing allow list to avoid any service disruption VMware SASE Points of Presence (PoPs) IP Address Ranges. Please remember to keep your existing IP addresses in your allow list and do not delete them.
SD-WAN Gateway Migration FAQs
Q: What is Gateway Migration?
A: VMware may decide to create new Gateways from time to time to:
-
Achieve operational efficiency. Please refer to SD-WAN Gateway Capacity Planning.
-
Migrate from legacy Gateways to VMware Edge Points of Presence (PoPs) Gateways so that enterprises can use the new services offered by VMware such for example SASE – Secure Access, and Cloud Web Security.
When this happens, existing Gateways may be replaced with new ones. When the existing or legacy Gateways are replaced, it is important to migrate all traffic to go through the new Gateways. This means migrating the Edges and NSD accordingly.
Q: What is the impact of a Gateway Migration?
A: The impact may vary based on the role configured for the Gateway. This is the expected impact for each Gateway role or Enterprise configuration:
-
Primary Gateway:
Primary Gateways are the Gateways used for Data Plane traffic that egresses to the internet. When a new Local Gateway is assigned, new Internet flows will use the new Gateway. Existing flows will use the previous Local Gateway until they time out to ensure there is no impact on users.
Note: A Gateway Rebalance is performed during the migration process to complete this change, there is no additional configuration required to complete this migration. -
Secondary Gateway:
Secondary Gateways supply regional control plane redundancy, and there is no impact to reassigning these Gateways. Reassignment happens instantly.
-
Super Gateway/Alternate Super Gateway:
Super and Alternate Gateways supply global control plane redundancy, and there is no impact to reassigning these Gateways. Reassignment happens instantly.
-
Secure VPN (Non-SD-WAN) Gateway:
Non-SD-WAN Gateways are the endpoints for your Non-SD-WAN Destinations. If your tunnel is authenticated via fully qualified domain name FQDN (e.g., Zscaler), there is no impact to reassigning these Gateways. Reassignment happens instantly. If your tunnel is authenticated via IP address and/or your peer is bound to a specific IP address (e.g., Cisco ISR), you must be involved in Gateway reassignment as it requires a change to your remote configuration.
These changes are avoided as much as possible, but Release 4.5.0 and above has introduced a self-service migration process for this, for instance in the case of Gateways being removed from service. Please note that for Non-SD-WAN tunnels authenticated via fully qualified domain name (FQDN), the self-service migration needs to be completed as well before the gateways are decommissioned.
Note: Please refer to SD-WAN Gateway Migration & Migrate Quiesced Gateways for more information related to Secure VPN (NSD) Gateway Migration.
-
Enterprises that have Allow Lists or custom Routing tables:
For Enterprises that use an allow list on a Firewall/SaaS provider, or have custom routing tables to enable connection to a VMware SD-WAN Gateway, service may be disrupted if the new gateway IP address is not entered into the allow list or routing table ahead of the migration. To avoid service disruptions, VMware recommends adding the IP address range to your Allow List or routing table, as described in VMware VECO and SASE Points of Presence (PoPs) IP Address Ranges.
Feedback
