Blog

Routed vApps Network connected to VLAN-backed External Network  With VMware NSX (NSX-T), a vApp Edge is backed by a standalone Tier-1 connected via Service interface (SI) to Org VDC network. The Org VDC network must be backed by an overlay segment (GENEVE), because VCD (VMware NSX backed) does not support connecting vApp Edge to a VLAN-backed Org VDC network. If the Org VDC network is directly connected to a VLAN-backed external network, such migration is not supported because of the above.  Create an External Network backed by a VMware NSX overlay segment instead and route it with NSX T0/T1 configured directly in NSX.  Fenced vApps  VMware NSX does not support vApp fencing (routing between internal and external subnets with the same subnet).  Deploy the fenced vApp to an Org VDC network with a subnet that does not overlap with the internal vApp network subnet. This must be done prior to the migration, as the Vmware NSX Migration for Vmware Cloud Director tool (MT) retains the source topology.  VDC Group  In NSX Data Center for vSphere (NSX-V) backed VDCs, VDC Groups (later renamed to Data Center Groups) allow for multiple Edge GWs and can be spread across multiple VCD and NSX-V instances. However, Data Center Groups supported by Vmware NSX only permit a single Edge Gateway in a single VCD instance.  Even with NSX Federation support in VCD 10.5 (allowing for multiple Vmware NSX instances in a single VCD instance), there is still not complete feature parity.  Remove the Data Center Groups before migration, migrate the workloads, and recreate (similar) networking topology after migration (NSX Multisite and stretched T0/T1 routers can be used).  IPsec Route-based VPN  As of VCD 10.5, policy-based VPN on Tier-1 backed Edge Gateway is supported. VMware NSX supports route-based VPN with dynamic routing (BGP) currently only at the Tier-0 level.  Deploy a dedicated Tier-0 Gateway for a tenant that requires an IPsec route-based VPN and configure it directly in VMware NSX. The BGP configuration can be done in VCD.  SSL VPN  VMware NSX does not provide SSL VPN support  Depending on the desired mix of features and support, select alternative solutions, including open source or a 3rd party commercial one.  https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/products/vmware-cloud-director-remote-access-vpn-integration-guide.pdf  https://blogs.vmware.com/cloudprovider/2020/11/vmware-cloud-director-vcd-cds-remote-access-vpn-integration-guide.html   L2 VPN  NSX-V and VMware NSX L2 VPN protocols are incompatible.   L2 VPN migration must be done manually, in which the VPN must be removed before migration and then reconfigured post-migration. This also includes replacing NSX-V standalone edges (if used) with autonomous VMware NSX Edges during the process.  https://docs.vmware.com/en/VMware-NSX/4.1/administration/GUID-BE8A3D3C-5E0D-4777-B4F4-908E64FCB771.html  Load Balancer application rules  NSX-V load balancer solution is based on HAProxy, while VMware NSX relies on the NSX Advanced Load Balancer (aka Avi). The application rules are mutually incompatible and have to be rewritten.  Starting from VCD 10.5, NSX Advanced Load Balancer HTTP Policies are exposed. As such, it is possible to remove the load balancing application rules before migration, migrate and upgrade to VCD 10.5, and then reconfigure the application rules. If an upgrade to VCD 10.5 is not planned, the policies can be configured from the backend of NSX ALB by the service provider on behalf of the tenant administrator(s).  Load Balancer custom health monitors  VCD currently does not support configuring load-balancing custom health monitors with NSX ALB.  Replace custom monitor with default monitors provided.  Syslog, CLI (SSH) on Edge Gateway  The VCD Edge Gateway is backed by a Tier-1 gateway running on VMware NSX Edge Node that can be shared with other Tier-1/Tier-0 objects.  Providing tenants CLI (SSH) access is only possible when the Edge Node is dedicated to them.  Similarly, the syslog data stream is shared across all objects. A Syslog filtering approach can be utilized as described here:  https://fojta.wordpress.com/2022/10/03/multitenant-logging-with-vmware-cloud-director/  OSPF dynamic routing   VCD with VMware NSX currently does not support OSPF.  Replace the OSPF with BGP before migration.  L2 Distributed Firewall (DFW) rules  Currently not supported in VCD with VMware NSX.  Replace with L3 DFW rules before migration  NAT64  Currently not supported in VCD with VMware NSX.  NAT64 only allows an IPv6-only client to initiate communications to an IPv4-only server. As a substitute for the NAT64 rule, a Load Balancer Virtual Service with IPv6 VIP and IPv4 backend servers can be utilized in VCD. The Load Balancer IPv6 Service Network Specification requires DHCPv6 in SLAAC mode to be configured beforehand. 

Source