You must check the state of the NSX Data Center for vSphere environment and fix any problems found. Also, depending on your environment, you might need to change your NSX Data Center for vSphere configuration before you can migrate to NSX-T Data Center.

System State

Check the following system states:

  • Verify that the NSX for vSphere components are in a green state on the NSX Dashboard.

  • Verify that all ESXi hosts are in an operational state. Address any problems with hosts including disconnected states. There must be no pending reboots or pending tasks for entering maintenance mode.

    Note:

    Hosts do not enter maintenance mode during migration.

  • Verify the publish status of Distributed Firewall and Service Composer to make sure that there are no unpublished changes.

General Configuration

  • Back up the NSX for vSphere and vSphere environments. See "NSX Backup and Restore" in the NSX Administration Guide.

  • The VXLAN port must be set to 4789. If your NSX for vSphere environment uses a different port, you must change it before you can migrate. See "Change VXLAN Port" in the NSX for vSphere NSX Administration Guide.

Controller Configuration

  • Migration coordinator does not support NSX for vSphere transport zones using multicast or hybrid replication mode. An NSX Controller cluster is required if VXLAN is in use. VLAN-backed micro-segmentation topologies do not use VXLAN and so do not require an NSX Controller cluster.

Host Configuration

  • On all host clusters in the NSX for vSphere environment, check these settings and update if needed:

  • If you have hosts that have NSX for vSphere installed, but are not added to a vSphere Distributed Switch, you must add them to distributed switches if you want to migrate them to NSX-T. See Configure Hosts Not Attached to vSphere Distributed Switches for more information.

  • On each cluster that has NSX for vSphere installed, check whether Distributed Firewall is enabled. You can view the enabled status at Installation & Upgrade > Host Preparation.

    If Distributed Firewall is enabled on any NSX for vSphere clusters before migration, Distributed Firewall is enabled on all clusters when they migrate to NSX-T. Determine the impact of enabling Distributed Firewall on all clusters and change the Distributed Firewall configuration if needed.

  • Verify that all hosts have only one VTEP interface configured. Check each host in Hosts and Clusters > Host > Configure > VMKernel adapters. Verify that there is only one interface with TCP/IP stack vxlan per host. Migrating hosts with multiple VTEPs is not supported.

Edge Services Gateway Configuration

  • Edge Services Gateways must use BGP for northbound routing. If OSPF is used, you must reconfigure to use BGP before you start the migration.

  • If you have prefix filters at the redistribution level, you must move them to the BGP neighbor level before migration.

  • NSX for vSphere supports policy-based IPSec VPN sessions where the local and peer subnets of two or more sessions overlap with each other. This behavior is not supported on NSX-T. You must reconfigure the subnets so they do not overlap before you start the migration. If this configuration issue is not resolved, the Migrate Configuration step fails.

  • If you have an Edge Services gateway performing one-armed load balancer function, you must change the following configurations if present before you import the configuration:

    • If the Edge Services Gateway has an interface configured for management, you must delete it before migration. You can have only one connected interface on an Edge Services Gateway providing one-arm load balancer function. If it has more than one interface, the Migrate Configuration step fails.

    • If the Edge Services Gateway firewall is disabled, and the default rule is set to deny, you must enable the firewall and change the default rule to accept. After migration the firewall is enabled on the tier-1 gateway, and the default rule accept takes effect. Changing the default rule to accept before migration prevents incoming traffic to the load balancer from being blocked.

  • Verify that Edge Services Gateways are all connected correctly to the topology being migrated. If Edge Services Gateways are part of the NSX for vSphere environment, but are not correctly attached to the rest of the environment, they are not migrated.

    For example, if an Edge Services Gateway is configured as a one-armed load balancer, but has one of the following configurations, it is not migrated:

    • The Edge Services Gateway does not have an uplink interface connected to a logical switch.

    • The Edge Services Gateway has an uplink interface connected to a logical switch, but the uplink IP address not does match the subnet associated with the distributed logical router that connects to the logical switch.

  • Customized MTU settings in the Edge Services Gateways routing interfaces are not migrated to NSX-T. Any logical router interfaces created in NSX-T use the global default MTU setting, which is 1500. If you want to ensure that all logical router interfaces have a larger MTU, you can change the global default MTU setting. Modify the MTU before you start the Migrate Edges step.

    • Use GET /api/v1/global-configs/RoutingGlobalConfig to retrieve the current configuration.

    • Modify the value of the global default MTU: logical_uplink_mtu

    • Use PUT /api/v1/global-configs/RoutingGlobalConfig to make the configuration change.

    You can also you can modify interface MTUs on a case-by-case basis before you start the Migrate Edges step.