NSD via VCG migration issues
Article ID: 376653
Updated On:
Products
Issue/Introduction
As part of the migration from AWS to the GCP cloud, VMware SD-WAN gateways will be transitioned to the GCP cloud. After the migration, we have observed several issues reported by customers:
1. Issue #1: Missing BGP over IPsec configuration or BGP session over the IPsec tunnel is down.
2. Issue #2: Difficulty in establishing IPsec tunnel with the secondary VCG node when both the primary and secondary NSD VCGs are in the same POP.
3. Issue #3: Incorrect NSD VCG IP address displayed in the IKE/IPsec template in the VCO UI.
4. Issue #4: IPsec tunnel flapping or down when the same NSD peer IP address is used in multiple NSD service profiles.
5. Issue #5: IPsec tunnel down or production impact after migration of the NSD VCGs.
Environment
NSD VCGs with the software version 6.x or above
Cause
Issue #1: The BGP AS number and peer information are not expected to be copied from the old VCG to the new VCG during the self-migration process. (VMware SD-WAN Gateway Migration - Limitations)
Issue #2: With the NSD portability feature, all VCGs within a POP will use a single public IP (i.e., the NSD portable IP) for establishing IPsec tunnels with peer devices. To prevent a single point of failure for IPSEC tunnels, primary and secondary NSD VCGs should not be located in the same POP or data center. If the primary and secondary NSD VCGs are in the same POP, only one IPsec tunnel can be established. However, each VCG will have a unique public IP for establishing VCMP tunnels with SD-WAN edges
Issue #3: The VCO UI IKE/IPsec template incorrectly displays the VCGs' unique public IP addresses rather than the NSD portable IP.
Issue #4: Using the same NSD peer IP address across multiple NSD service profiles is unsupported. Similarly, an NSD service profile should not be attached to multiple segments. Despite this, some customers have reported IPsec tunnel issues after migrating NSD VCGs, due to the use of the same NSD peer IP address across multiple profiles.
Issue #5 : Incorrect IPsec configuration between the new NSD VCG and the IPsec peer device.
Resolution
Issue #1: If the customer is using BGP over IPsec within an NSD via VCG service profile, it is recommended that they take a screenshot of the BGP configuration through the VCO UI. This will enable them to reconfigure BGP settings after completing the NSD VCG migration.
Issue #2: If the primary and secondary NSD VCGs are located in the same POP, please contact the Broadcom SD-WAN Support team and ask the support engineer to manually move one of the NSD VCGs to a different POP.
Issue #3: This is a cosmetic issue, and the SD-WAN engineering team is working on a fix to display the correct IP address in the IKE/IPsec template. In the meantime, we advise customers to check the correct VCG IP address on the Self Migration page.
Issue #4: Customers should avoid reusing the same NSD peer IP address across multiple NSD service profiles. If a customer currently uses the same NSD peer IP address in multiple profiles, they should update it to a unique public IP address. If this is not feasible, please contact Broadcom support to explore possible exceptional case workarounds.
Issue #5: After completing the NSD VCG migration, ensure that the peer-end IPsec device is updated with the correct NSD Portable IP address, IKE/IPsec parameters, including the "Local Authentication ID" and NAT-T configuration.
Please be aware that NAT-T must be enabled on the IPSEC configuration of the peer end device. While NAT-T was not a required configuration with the old VCG, it is essential to enable NAT-T on the peer end IPSEC device following the migration to establish an IPSEC tunnel with the new VCGs.
We recommend using an FQDN-based or IP+FQDN-based Local Authentication ID where possible. Please refer the KB: KB-376599
If the tunnel remains down (or) flapping (or) if there is any impact on production traffic, please contact Broadcom support for assistance. KB: KB - 142884
Additional Information
Feedback
