Routed vApps Community linked to VLAN-backed Exterior Community
With VMware NSX (NSX-T), a vApp Edge is backed by a standalone Tier-1 linked by way of Service interface (SI) to Org VDC community. The Org VDC community should be backed by an overlay section (GENEVE), as a result of VCD (VMware NSX backed) doesn’t help connecting vApp Edge to a VLAN-backed Org VDC community. If the Org VDC community is instantly linked to a VLAN-backed exterior community, such migration isn’t supported due to the above.
Create an Exterior Community backed by a VMware NSX overlay section as a substitute and route it with NSX T0/T1 configured instantly in NSX.
Fenced vApps
VMware NSX doesn’t help vApp fencing (routing between inside and exterior subnets with the identical subnet).
Deploy the fenced vApp to an Org VDC community with a subnet that doesn’t overlap with the inner vApp community subnet. This should be completed previous to the migration, because the Vmware NSX Migration for Vmware Cloud Director device (MT) retains the supply topology.
VDC Group
In NSX Information Middle for vSphere (NSX-V) backed VDCs, VDC Teams (later renamed to Information Middle Teams) permit for a number of Edge GWs and might be unfold throughout a number of VCD and NSX-V cases. Nonetheless, Information Middle Teams supported by Vmware NSX solely allow a single Edge Gateway in a single VCD occasion. Even with NSX Federation help in VCD 10.5 (permitting for a number of Vmware NSX cases in a single VCD occasion), there’s nonetheless not full function parity.
Take away the Information Middle Teams earlier than migration, migrate the workloads, and recreate (comparable) networking topology after migration (NSX Multisite and stretched T0/T1 routers can be utilized).
IPsec Route-based VPN
As of VCD 10.5, policy-based VPN on Tier-1 backed Edge Gateway is supported. VMware NSX helps route-based VPN with dynamic routing (BGP) at present solely on the Tier-0 stage.
Deploy a devoted Tier-0 Gateway for a tenant that requires an IPsec route-based VPN and configure it instantly in VMware NSX. The BGP configuration might be completed in VCD.
NSX-V load balancer answer is predicated on HAProxy, whereas VMware NSX depends on the NSX Superior Load Balancer (aka Avi). The applying guidelines are mutually incompatible and must be rewritten.
Ranging from VCD 10.5, NSX Superior Load Balancer HTTP Insurance policies are uncovered. As such, it’s attainable to take away the load balancing utility guidelines earlier than migration, migrate and improve to VCD 10.5, after which reconfigure the applying guidelines. If an improve to VCD 10.5 isn’t deliberate, the insurance policies might be configured from the backend of NSX ALB by the service supplier on behalf of the tenant administrator(s).
Load Balancer customized well being displays
VCD at present doesn’t help configuring load-balancing customized well being displays with NSX ALB.
Exchange customized monitor with default displays offered.
Syslog, CLI (SSH) on Edge Gateway
The VCD Edge Gateway is backed by a Tier-1 gateway operating on VMware NSX Edge Node that may be shared with different Tier-1/Tier-0 objects.
Exchange the OSPF with BGP earlier than migration.
L2 Distributed Firewall (DFW) guidelines
At present not supported in VCD with VMware NSX.
Exchange with L3 DFW guidelines earlier than migration
NAT64
At present not supported in VCD with VMware NSX.
NAT64 solely permits an IPv6-only shopper to provoke communications to an IPv4-only server. As an alternative choice to the NAT64 rule, a Load Balancer Digital Service with IPv6 VIP and IPv4 backend servers might be utilized in VCD. The Load Balancer IPv6 Service Community Specification requires DHCPv6 in SLAAC mode to be configured beforehand.