Detailed Feature Support for Migration Coordinator

NSX for vSphere (NSX-v) features and configurations that can be migrated are listed below.

Platform Support

See the VMware Interoperability Matrix for supported versions of ESXi and vCenter Server.

NSX-v Configuration	Supported	Details
NSX Data Center for vSphere with vSAN or iSCSI on vSphere Distributed Switch	Yes
Pre-existing NSX-T configuration	No	Deploy a new NSX-T Data Center environment to be the destination for the NSX Data Center for vSphere migration. During the Import Configuration step, all NSX Edge node interfaces in the destination NSX-T Data Center environment are shut down. If the destination NSX-T Data Center environment is already configured and is in use, starting the configuration import will interrupt traffic.
Cross vCenter NSX	(NSX-T 3.1) No (NSX-T 3.1.1 and later) Yes if the NSX-v deployment has an NSX Manager in primary mode and no secondary NSX Managers.	Starting in NSX-T 3.1.1, migration of a single site NSX for vSphere deployment that contains an NSX Manager in primary mode, no secondary NSX Managers, and with universal objects on the primary site, is supported. Such a single site NSX for vSphere deployment is migrated to a single site NSX-T environment (non-federated) with local objects. Migration of a true cross-vCenter NSX-V deployment with a primary NSX Manager and multiple secondary NSX Managers is not supported. Migration Coordinator will only migrate from an NSX-V Manager with the role of Primary or Standalone. You can modify the NSX-V environment by changing the status of the secondary managers in order to migrate each NSX-V environment independently.
NSX Data Center for vSphere with a Cloud Management Platform, Integrated Stack Solution, or PaaS Solution	Yes	Migration of NSX for vSphere with vRealize Automation is supported if the integrated environment is configured in a supported topology. See Topologies Supported for Integration with vRealize Automation for details. Contact your VMware representative before proceeding with migration. Scripts and integrations might break if you migrate the integrated environments: For example: NSX for vSphere and VMware Integrated Openstack NSX for vSphere and vCloud Director NSX for vSphere with Integrated Stack Solution NSX for vSphere with PaaS Solution such as Pivotal Cloud Foundry, RedHat OpenShift NSX for vSphere with vRealize Operations workflows

vSphere and ESXi Features

NSX-v Configuration	Supported	Details
ESXi host already in maintenance mode (no VMs)	Yes
Network I/O Control (NIOC) version 3	Yes
Network I/O Control (NIOC) version 2	No
Network I/O Control (NIOC) having vNIC with reservation	No
vSphere Standard Switch	No	VMs and VMkernel interfaces on VSS are not migrated. NSX Data Center for vSphere features applied to the VSS cannot be migrated.
vSphere Distributed Switch	Yes
Stateless ESXi	No
Host profiles	No
ESXi lockdown mode	No	Not supported in NSX-T.
ESXi host pending maintenance mode task.	No
Disconnected ESXi host in vCenter cluster	No
vSphere FT	No
vSphere DRS fully automated	Yes	Supported starting in vSphere 7.0
vSphere High Availability	Yes (when maintenance mode is used)
Traffic filtering ACL	No
vSphere Health Check	No
SRIOV	No
vmknic pinning to physical NIC	No
Private VLAN	No
Ephemeral dvPortGroup	No
DirectPath IO	No
L2 security	No
Learn switch on virtual wire	No
Hardware Gateway (Tunnel endpoint integration with physical switching hardware)	No
SNMP	No
Disconnected vNIC in VM	No	Due to ESX 6.5 limitation, stale entries might present on DVFilter for disconnected VMs. Reboot the VM as a workaround.
VXLAN port number other than 4789	No
Multicast Filtering Mode	No
Hosts with multiple VTEPs	Yes

NSX Manager Appliance System Configuration

NSX-v Configuration	Supported	Details
NTP server/time setting	Yes
Syslog server configuration	Yes
Backup configuration	Yes	If needed, change NSX Data Center for vSphere passphrase to match NSX-T Data Center requirements. It must be at least 8 characters long and contain the following: At least one lowercase letter At least one uppercase letter At least one numeric character At least one special character
FIPS	No	FIPS on/off not supported by NSX-T.
Locale	No	NSX-T only supports English locale
Appliance certificate	No

Role-Based Access Control

NSX-v Configuration	Supported	Details
Local users	No
NSX roles assigned to a vCenter user added via LDAP	Yes	VMware Identity Manager must be installed and configured to migrate user roles for LDAP users.
NSX roles assigned to a vCenter group	No

Certificates

NSX-v Configuration	Supported	Details
Certificates (Server, CA signed)	Yes	This applies to certificates added through truststore APIs only.

Operations

Details	Supported	Notes
Discovery protocol CDP	No
Discovery protocol LLDP	Yes	The listen mode is turned on by default and can’t be changed in NSX-T. Only the Advertise mode can be modified.
PortMirroring: Encapsulated remote Mirroring Source (L3)	Yes	Only L3 session type is supported for migration
PortMirroring: Distributed PortMirroring Remote Mirroring Source Remote Mirroring Destination Distributed Port Mirroring (legacy)	No
L2 IPFIX	Yes	LAG with IPFIX is not supported
Distributed Firewall IPFIX	No
MAC Learning	Yes	You must enable (accept) forged transmits.
Hardware VTEP	No
Promiscuous Mode	No
Resource Allocation	No	vNIC enabled with resource allocation is not supported
IPFIX – Internal flows	No	IPFIX with InternalFlows is not supported

Switch

NSX-v Configuration	Supported	Details
L2 Bridging	No
Trunk VLAN	Yes	Trunk uplink portgroups must be configured with a VLAN range of 0-4094.
VLAN Configuration	Yes	Configuration with only VLAN (no VXLAN) is supported.
Teaming and Failover: Load Balancing Uplink Failover Order	Yes	Supported options for load balancing (teaming policy): Use explicit failover order Route based on source MAC hash Source port (starting with NSX-T 3.1.3). Other load balancing options are not supported.
Teaming and Failover: Network Failure Detection Notify Switches Reverse Policy Rolling Order	No
LACP	Yes	For VDS 7.0 and later, the LACP functionality is not modified during migration. For earlier versions of VDS, a new N-VDS switch replaces the VDS. This will lead to traffic loss during host migration. IPFIX configured on DVS (not DFW IPFIX) is not supported with LACP

Switch Security and IP Discovery

NSX-v Configuration	Supported fro Migration	Details
IP Discovery (ARP, ND, DHCPv4 and DHCPv6)	Yes	The following binding limits apply on NSX-T for migration: 128 for ARP discovered IPs 128 for DHCPv4 discovered IPs 15 for DHCPv6 discovered IPs 15 for ND discovered IPs
SpoofGuard (Manual, TOFU, Disabled)	Yes
Switch Security (BPDU Filter, DHCP client block, DHCP server block, RA guard)	Yes
Migrating datapath bindings from Switch Security module in NSX Data Center for vSphere to Switch security module in NSX-T	Yes	If SpoofGuard is enabled, bindings are migrated from the Switch Security module to support ARP suppression. VSIP – Switch security not supported as VSIP bindings are migrated as statically configured rules.
Discovery profiles	Yes	The ipdiscovery profiles are created after migration using the IP Discovery configuration for the logical switch and the global and cluster ARP and DHCP configuration.

Central Control Plane

NSX-v Configuration	Supported	Details
VTEP replication per logical switch (VNI) and routing domain	Yes
MAC/IP replication	No
NSX Data Center for vSphere transport zones using multicast or hybrid replication mode	No
NSX Data Center for vSphere transport zones using unicast replication mode	Yes

NSX Edge Features

For full details on supported topologies, see Supported Topologies.

NSX-v Configuration	Supported	Details
Routing between Edge Service Gateway and northbound router or virtual tunnel interface	Yes	BGP is supported. Static routes are supported. OSPF is not supported.
Routing between Edge Services Gateway and Distributed Logical Router	Yes	Routes are converted to static routes after migration.
Load balancer	Yes	See Supported Topologies for details.
VLAN-backed Micro-Segmentation environment	Yes	See Supported Topologies for details.
NAT64	No	Not supported in NSX-T.
Node level settings on Edge Services Gateway or Distributed Logical Router	No	Node level settings, for example, syslog or NTP server, are not supported.
IPv6	No
Unicast Reverse Path Filter (URPF) configuration for Edge Services Gateway interfaces	No	URPF on NSX-T gateway interfaces is set to Strict.
Maximum Transmission Unit (MTU) configuration Edge Services Gateway interfaces	No	See Modify NSX Edge Node Configuration Before Migrating Edges for information about changing the default MTU on NSX-T.
IP Multicast routing	No
Route Redistribution Prefix Filters	No
Default originate	No	Not supported in NSX-T.

Edge Firewall

NSX-v Configuration	Supported	Details
Firewall Section: Display name	Yes	Firewall sections can have a maximum of 1000 rules. If a section contains more than 1000 rules, it is migrated as multiple sections.
Action for default rule	Yes	NSX Data Center for vSphere API: GatewayPolicy/action NSX-T API: SecurityPolicy.action
Firewall Global Configuration	No	Default timeouts are used
Firewall Rule	Yes	NSX Data Center for vSphere API: firewallRule NSX-T API: SecurityPolicy
Firewall Rule: name	Yes
Firewall Rule: rule tag	Yes	NSX Data Center for vSphere API: ruleTag NSX-T API: Rule_tag
Sources and destinations in firewall rules: Grouping objects IP addresses	Yes	NSX Data Center for vSphere API: source/groupingObjectId source/ipAddress NSX-T API: source_groups NSX Data Center for vSphere API: destination/groupingObjectId destination/ipAddress NSX-T API: destination_groups
Firewall rule sources and destinations: vNIC Group	No
Services (applications) in firewall rules: Service Service Group Protocol/port/source port	Yes	NSX Data Center for vSphere API: application/applicationId application/service/protocol application/service/port application/service/sourcePort NSX-T API: Services
Firewall Rule: Match translated	No	Match translated must be ‘false’.
Firewall Rule: Direction	Yes	Both APIs: direction
Firewall Rule: Action	Yes	Both APIs: action
Firewall Rule: Enabled	Yes	Both APIs: enabled
Firewall Rule: Logging	Yes	NSX Data Center for vSphere API: logging NSX-T API: logged
Firewall Rule: Description	Yes	Both APIs: description

Edge NAT

NSX-v Configuration	Supported	Details
NAT rule	Yes	NSX Data Center for vSphere API: natRule NSX-T API: /nat/USER/nat-rules
NAT rule: rule tag	Yes	NSX Data Center for vSphere API: ruleTag NSX-T API: rule_tag
NAT rule: action	Yes	NSX Data Center for vSphere API: action NSX-T API: action
NAT rule: original address (Source address for SNAT rules, and the destination address for DNAT rules.)	Yes	NSX Data Center for vSphere API: originalAddress NSX-T API: source_network for SNAT rule or destination_network for DNAT rule
NAT rule: translatedAddress	Yes	NSX Data Center for vSphere API: translatedAddress NSX-T API: translated_network
NAT rule: Applying NAT rule on a specific interface	No	Applied on must be “any”.
NAT rule: logging	Yes	NSX Data Center for vSphere API: loggingEnabled NSX-T API: logging
NAT rule: enabled	Yes	NSX Data Center for vSphere API: enabled NSX-T API: disabled
NAT rule: description	Yes	NSX Data Center for vSphere API: description NSX-T API: description
NAT rule: protocol	Yes	NSX Data Center for vSphere API: protocol NSX-T API: Service
NAT rule: original port (source port for SNAT rules, destination port for DNAT rules)	Yes	NSX Data Center for vSphere API: originalPort NSX-T API: Service
NAT rule: translated port	Yes	NSX Data Center for vSphere API: translatedPort NSX-T API: Translated_ports
NAT rule: Source address in DNAT rule	Yes	NSX Data Center for vSphere API: dnatMatchSourceAddress NSX-T API: source_network
NAT rule: Destination address in SNAT rule	Yes	NSX Data Center for vSphere API: snatMatchDestinationAddress NSX-T API: destination_network
NAT rule: Source port in DNAT rule	Yes	NSX Data Center for vSphere API: dnatMatchSourcePort NSX-T API: Service
NAT rule: Destination port in SNAT rule	Yes	NSX Data Center for vSphere API: snatMatchDestinationPort NSX-T API: Service
NAT rule: rule ID	Yes	NSX Data Center for vSphere API: ruleID NSX-T API: id and display_name

L2VPN

NSX-v Configuration	Supported	Details
L2VPN configuration based on IPSec using pre-shared key (PSK)	Yes	Supported if the networking being stretched over L2VPN is an overlay logical switch. Not supported for VLAN networks.
L2VPN configuration based on IPSec using certificate-based authentication	No
L2VPN configuration based on SSL	No
L2VPN configurations with local egress optimizations	No
L2VPN client mode	No

L3VPN

NSX-v Configuration	Supported	Details
Dead Peer Detection	Yes	Dead Peer Detection supports different options on NSX Data Center for vSphere and NSX-T. You might want to consider using BGP for faster convergence or configure a peer to perform DPD if it is supported.
Changed Dead Peer Detection (dpd) default values for: dpdtimeout dpdaction	No	In NSX-T, dpdaction is set to “restart” and cannot be changed. If NSX Data Center for vSphere setting for dpdtimeout is set to 0, dpd is disabled in NSX-T. Otherwise, any dpdtimeout settings are ignored and the default value is used.
Changed Dead Peer Detection (dpd) default values for: dpddelay	Yes	NSX Data Center for vSphere dpdelay maps to NSX-T dpdinternal.
Overlapping local and peer subnets of two or more sessions.	No	NSX Data Center 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.
IPSec sessions with peer endpoint set as any.	No	Configuration is not migrated.
Changes to the extension securelocaltrafficbyip.	No	NSX-T Service Router does not have any local generated traffic that needs to be sent over tunnel.
Changes to these extensions: auto, sha2_truncbug, sareftrack, leftid, leftsendcert, leftxauthserver, leftxauthclient, leftxauthusername, leftmodecfgserver, leftmodecfgclient, modecfgpull, modecfgdns1, modecfgdns2, modecfgwins1, modecfgwins2, remote_peer_type, nm_configured, forceencaps,overlapip, aggrmode, rekey, rekeymargin, rekeyfuzz, compress, metric,disablearrivalcheck, failureshunt,leftnexthop, keyingtries	No	Those extensions are not supported on NSX-T and changes to them are not migrated.

Load Balancer

NSX-v Configuration	Supported	Details
Monitor / health-checks for: LDAP DNS MSSQL	No	If an unsupported monitor is configured, the monitor is ignored and the associated pool has no monitor configured. You can attach it to a new monitor after migration has finished.
Application rules	No	NSX Data Center for vSphere uses application rules based on HAProxy to support L7. In NSX-T, the rules are based on NGINX. The application rules cannot be migrated. You must create new rules after migration.
L7 virtual server port range	No
IPv6	No	If IPv6 is used in virtual server, the whole virtual server would be ignored. If IPv6 is used in pool, the pool would be still migrated, however, the related pool member would be removed.
URL, URI, HTTPHEADER algorithms	No	If used in a pool, the pool is not migrated.
Isolated pool	No	The pool is not migrated.
LB pool member with different monitor port	No	The pool member which has different monitor port is not migrated.
Pool member minConn	No	Configuration is not migrated.
Monitor extension	No	Configuration is not migrated.
SSL sessionID persistence / table	No	Configuration is not migrated, and the associated virtual server has no persistence setting.
MSRDP persistence / session table	No	Configuration is not migrated, and the associated virtual server has no persistence setting.
Cookie app session / session table	No	Configuration is not migrated, and the associated virtual server has no persistence setting.
App persistence	No	Configuration is not migrated, and the associated virtual server has no persistence setting.
Monitor for: Explicit escape Quit Delay	No
Monitor for: Send Expect Timeout Interval maxRetries	Yes
Haproxy Tuning/IPVS Tuning	No
Pool IP filter IPv4 addresses	Yes	IPv4 IP addresses are supported. If Any is used, only the IPv4 addresses of the IP pool are migrated.
Pool IP Filter IPv6 addresses	No
Pool containing unsupported grouping object: Cluster Datacenter Distributed port group MAC set Virtual App	No	If a pool includes an unsupported grouping object, those objects are ignored, and the pool is created with supported grouping object members. If there are no supported grouping object members, then an empty pool is created.

DHCP and DNS

Table 1. DHCP Configuration Topologies

NSX-v Configuration	Supported	Details
DHCP Relay configured on Distributed Logical Router pointing to a DHCP Server configured on a directly connected Edge Services Gateway	Yes	The DHCP Relay server IP must be one of the Edge Services Gateway’s internal interface IPs. The DHCP Server must be configured on an Edge Services Gateway that is directly connected to the Distributed Logical Router configured with the DHCP relay. It is not supported to use DNAT to translate a DHCP Relay IP that does not match an Edge Services Gateway internal interface.
DHCP Relay configured on Distributed Logical Router only, no DHCP Server configuration on connected Edge Services Gateway	No
DHCP Server configured on Edge Services Gateway only, no DHCP Relay configuration on connected Distributed Logical Router	No

Table 2. DHCP Features

NSX-v Configuration	Supported	Details
IP Pools	Yes
Static bindings	Yes
DHCP leases	Yes
General DHCP options	Yes
Disabled DHCP service	No	In NSX-T you cannot disable the DHCP service. If there is a disabled DHCP service on NSX Data Center for vSphere it is not migrated.
DHCP option: "other"	No	The "other" field in dhcp options is not supported for migration. For example, dhcp option '80' is not migrated. <dhcpOptions> <other> <code>80</code> <value>2f766172</value> </other> </dhcpOptions>
Orphaned ip-pools/bindings	No	If ip-pools or static-bindings are configured on a DHCP Server but are not used by any connected logical switches, these objects are skipped from migration.
DHCP configured on Edge Service Gateway with directly connected logical switches	No	During migration, directly connected Edge Service Gateway interfaces are migrated as centralized service ports. However, NSX-T does not support DHCP service on a centralized service port, so the DHCP service configuration is not migrated for these interfaces.

Table 3. DNS Features

NSX-v Configuration	Supported	Details
DNS views	Yes	Only the first dnsView is migrated to the NSX-T default DNS forwarder zone.
DNS configuration	Yes	You must provide available DNS listener IPs for all Edge Nodes. A message is displayed during Resolve Configuration to prompt for this.
DNS – L3 VPN	Yes	You must add the newly configured NSX-T DNS listener IPs into the remote L3 VPN prefix list. A message is displayed during Resolve Configuration to prompt for this.
DNS configured on Edge Service Gateway with directly connected logical switches	No	During migration, directly connected Edge Service Gateway interfaces are migrated as centralized service ports. However, NSX-T does not support DNS Service on a centralized service port, so the DNS Service configuration is not migrated for these interfaces.

Distributed Firewall (DFW)

NSX-v Configuration	Supported	Details
Identity-based Firewall	No
Section - Name Description TCP Strict Stateless Firewall	Yes	If a firewall section has more than 1000 rules, then the migrator will migrate the rules in multiple sections of 1000 rules each.
Universal Sections	(NSX-T 3.1) No (NSX-T 3.1.1 and later) Yes if the NSX-v deployment has an NSX Manager in primary mode and no secondary NSX Managers.
Rule – Source / Destination: IP Address / Range / CIDR Logical Port Logical Switch	Yes
Rule – Source / Destination: VM Logical Port Security Group / IP Set / MAC Set	Yes	maps to Security Group
Rule – Source / Destination: Cluster Datacenter DVPG vSS Host	No
Rule – Source / Destination: Universal Logical Switch	(NSX-T 3.1) No (NSX-T 3.1.1 and later) Yes if the NSX-v deployment has an NSX Manager in primary mode and no secondary NSX Managers.
Rule – Applied To: ANY	Yes	maps to Distributed Firewall
Rule – Applied To: Security Group Logical Port Logical Switch VM	Yes	maps to Security Group
Rule – Applied To: Cluster Datacenter DVPG vSS Host	No
Rule – Applied To: Universal Logical Switch	(NSX-T 3.1) No (NSX-T 3.1.1 and later) Yes if the NSX-v deployment has an NSX Manager in primary mode and no secondary NSX Managers.
Rules Disabled in Distributed Firewall	Yes
Disabling Distributed Firewall on a cluster level	No	When Distributed Firewall is enabled on NSX-T, it is enabled on all clusters. You cannot enable it on some clusters and disable on others.
DFW Exclusion List	No	DFW exclusion lists are not migrated. You need to re-create them on NSX-T after migration.

Note: When migrating DFW rules, be sure to migrate the objects referenced by the rules also. NSX-T cannot apply a rule if the objects referenced by the rule are not part of the NSX-T network.

Partner Services: East-West Network Introspection

NSX-v Configuration	Supported	Details
Service	No	Service registration is not migrated. Partner must register the service with NSX-T before migration.
Vendor Template	No	Vendor template is not migrated. Partner must register the vendor template with NSX-T before migration.
Service Profile	No	Service profiles are not migrated. Either you or the partner must create the service profiles before migration. In the Resolve Configuration step of the migration, the migration coordinator prompts you to map each NSX for vSphere service profile to an NSX-T service profile. If you skip the mapping of service profiles, the rules that use these service profiles are not migrated. Migration coordinator creates a service chain in NSX-T for each service profile in NSX for vSphere. The service chain is created with the following naming convention: Service-Chain-service_profile_name The same service profile is used in the forward path and reverse path of the service chain.
Service Instance	No	Partner service virtual machines (SVMs) are not migrated. The NSX for vSphere partner SVMs cannot be used in NSX-T. For east-west Network Introspection service in NSX-T, partner service VMs must be deployed on an overlay segment.
Section Name ID Description TCP Strict Stateless Firewall	Yes	A section maps to a redirection policy. ID is user-defined, and not auto-generated in NSX-T. If a firewall section in NSX for vSphere has more than 1000 rules, migration coordinator migrates the rules in multiple sections of 1000 rules each. For example, if a section contains 2500 rules, the migration coordinator creates three policies: Policy 1 with 1000 rules, Policy 2 with 1000 rules, and Policy 3 with 500 rules. Stateful or stateless firewall rules in NSX for vSphereare migrated to stateful or stateless redirection rules in NSX-T.
Partner Services: Rules
Name	Yes
Rule ID	Yes	Rule ID is system generated. It can be different from the rule ID in NSX for vSphere.
Negate Source	Yes
Negate Destination	Yes
Source/Destination VM Security Group IP Set vNIC	Yes
Services/Service Groups	Yes	For details, see the Services and Service Groups table.
Advanced Settings Direction Packet Type Rule Tag Comments Log	Yes
Service Profile and Action Service Name Service Profile Action Service Profile Bindings	Yes	A service profile binding can have Distributed Virtual Port Groups (DVPG), Logical Switches, and Security Groups as its members. A service profile binding in NSX for vSphere maps to the Applied To field of a redirection rule in NSX-T. Applied To field accepts only Groups, and this field determines the scope of the rule. In NSX-T, rule redirection is at the level of a policy. All rules in a redirection policy have the same scope (Applied To). Applied To field in an NSX-T redirection rule can have a maximum of 128 members. If the number of members in a service profile binding exceeds 128, reduce them to <= 128 before starting the migration. For example, assume that a service profile binding has 140 members (Security Groups). Do the following steps in NSX for vSphere before starting the migration: Create a dummy Security Group. Move 13 Security Groups to this dummy Security Group. In other words, the dummy Security Group has 13 members. Remove the binding of these 13 Security Groups from the service profile. You now have 127 members in the service profile binding (140-13). Add the dummy Security Group to the service profile binding. Now, the total number of members in the service profile binding is 128 (127 + 1), and it is within the maximum limit of the migration coordinator.
Enable/Disable Rule	Yes

Service Segment

Migration coordinator creates a service segment in the overlay transport zone that you select in the Resolve Configuration step of the migration. In the NSX for vSphere environment, if the VXLAN transport zone is not prepared with NSX for vSphere, the migration coordinator provides you the option to select the default overlay transport zone in NSX-T to create the service segment. If one or multiple VXLAN transport zones are prepared with NSX for vSphere, you must select any one overlay transport zone to create the service segment in NSX-T.

Service Profile Priority

In NSX for vSphere, a service profile has a priority. If a service has multiple service profiles, and multiple profiles are bound to the same vNIC, the service profile with higher priority is applied first on the vNIC. However, in NSX-T, service profile does not have a priority. When multiple redirection rules have the same Applied To setting, the rule order decides which rule is hit first. In other words, the migration coordinator places the rules with a higher profile priority before the rules with a lower profile priority in the NSX-T rule table. For a detailed example, see scenario 2 in Order of Migrated Network Introspection Rules in NSX-T Data Center.

Service Precedence

To redirect traffic to multiple services, NSX for vSphere uses multiple DVFilter slots in the service insertion data path. One DVFilter slot is used to redirect traffic to one service. A service with high precedence is placed higher in the slot compared to a service with low precedence. In NSX-T, only a single DVFilter slot is used and it redirects traffic to a service chain. After migration to NSX-T, the rules that use a partner service with higher precedence are placed before the rules that use a partner service with a lower precedence. For a detailed example, see scenario 3 in Order of Migrated Network Introspection Rules in NSX-T Data Center.

Migration coordinator does not support redirection of traffic on a vNIC to multiple partner services. Redirection to only a single partner service is supported. Although, all the NSX for vSphere rules are migrated to NSX-T, the migrated rule configurations use a service chain with only one service profile. You cannot modify an existing service chain that is used in redirection rules.

Workaround: To redirect traffic on a vNIC to multiple services, create a new service chain and define the order of service profiles in the service chain. Update the migrated rules to use this new service chain.

Network Introspection Service on VMs Connected to a VM Network

In the NSX-v environment, if Network Introspection service rules are running on VMs that are connected to a VM Network, these VMs lose security protection after host migration. To ensure that the Network Introspection rules are enforced on the vNICs of these VMs post host migration, you must connect these VMs to an NSX-T segment.

Grouping Objects and Service Composer

IP Sets and MAC Sets are migrated to NSX-T Data Center as groups. See Inventory > Groups in the NSX-T Manager web interface.

Table 4. IP Sets and MAC Sets

NSX-v Configuration	Supported	Details
IP Sets	Yes	IP sets with up to 2 million members (IP addresses, IP address subnets, IP ranges) can be migrated. IP sets with more members are not migrated.
Mac Sets	Yes	MAC sets with up to 2 million members can be migrated. MAC sets with more members are not migrated.

Security Groups are supported for migration with the limitations listed. Security Groups are migrated to NSX-T Data Center as Groups. See Inventory > Groups in the NSX-T Manager web interface.

NSX Data Center for vSphere has system-defined and user-defined Security Groups. These are all migrated to NSX-T as user-defined Groups.

The total number of ‘Groups’ after migration might not be equal to the number of Security Groups on NSX-v. For example, a Distributed Firewall rule containing a VM as its source would be migrated into a rule containing a new Group with the VM as its member. This increases the total number of groups on NSX-T after migration.

Table 5. Security Groups

NSX-v Configuration	Supported	Details
Security Group with members that don’t exist	No	If any of the members of the Security Group do not exist, then the Security Group is not migrated.
Security Group that contains a Security Group with unsupported members	No	If any members of the Security Group are not supported for migration, the Security Group is not migrated. If a Security Group contains a Security Group with unsupported members, the parent Security Group is not migrated.
Exclude membership in Security Group	No	Security Groups with an exclude member directly or indirectly (via nesting) are not migrated
Security Group Static Membership	Yes	A Security Group can contain up to 500 static members. However, system-generated static members are added if the Security Group is used in Distributed Firewall rules, lowering the effective limit to 499 or 498. If the Security Group is used in either layer 2 or layer 3 rules, one system-generated static member is added to the Security Group. If the Security Group is used in both layer 2 and layer 3 rules, two system-generated static members are added. If any members do not exist during the Resolve Configuration step, the security group is not migrated.
Security Group Member Types (Static or Entity Belongs To): Cluster Datacenter Directory Group Distributed Port Group Legacy Port Group / Network Resource Pool vApp	No	If a security group contains any of the unsupported member types, the security group is not migrated.
Security Group Member Types (Static or Entity Belongs To): Security Group IP Sets MAC Sets	Yes	Security groups, IP sets, and MAC sets are migrated to NSX-T as Groups. If an NSX for vSphere security group contains an IP set, MAC set, or nested security group as a static member, the corresponding Groups are added to the parent Group. If one of these static members was not migrated to NSX-T, the parent security group does not migrate to NSX-T. For example, an IP set with more than 2 million members cannot migrate to NSX-T. Therefore, a security group that contains an IP set with more than 2 million members cannot migrate.
Security Group Member Types (Static or Entity Belongs To): Logical Switch (Virtual Wire)	Yes	If a security group contains logical switches that do not migrate to NSX-T segments, the security group does not migrate to NSX-T.
Security Group Member Types (Static or Entity Belongs To): Security Tag	Yes	If a security tag is added to the security group as a static member or as a dynamic member using Entity Belongs To, the security tag must exist for the security group to be migrated. If the security tag is added to the security group as a dynamic member (not using Entity Belongs To), the existence of the security tag is not checked before migrating the security group.
Security Group Member Types (Static or Entity Belongs To): vNIC Virtual Machine	Yes	vNICs and VMs are migrated as an ExternalIDExpression. Orphaned VMs (VMs deleted from hosts) are ignored during Security Group migration. Once the Groups appear on NSX-T, the VM and vNIC memberships are updated after some time. During this intermediate time, there can be temporary groups and their temporary groups might appear as members. However, once the Host Migration has finished, these extra temporary groups are no longer seen.
Using “Matches regular expression” operator for dynamic membership	No	This affects Security Tag and VM Name only. “Matches regular expression” is not available for other attributes.
Using other available operators for dynamic membership criteria for attributes: Security Tag VM Name Computer Name Computer OS Name	Yes	Available operators for VM Name, Computer Name, and Computer OS Name are Contains, Ends with, Equals to, Not equals to, Starts with. Available operators for Security Tag are Contains, Ends with, Equals to, Starts with.
Entity Belongs to criteria	Yes	The same limitations for migrating static members apply to Entity Belongs to criteria. For example, if you have a Security Group that uses Entity Belongs to a cluster in the definition, the Security Group is not migrated. Security Groups that contain Entity Belongs to criteria that are combined with AND are not migrated.
Dynamic membership criteria operators (AND, OR) in Security Group	Yes.	When you define dynamic membership for an NSX Data Center for vSphere Security Group, you can configure the following: One or more dynamic sets. Each dynamic set can contain one or more dynamic criteria. For example, “VM Name Contains web”. You can select whether to match Any or All dynamic criteria within a dynamic set. You can select to match with AND or OR across dynamic sets. NSX Data Center for vSphere does not limit the number of dynamic criteria, dynamic sets, and you can have any combinations of AND and OR. In NSX-T Data Center, you can have a group with five expressions. NSX Data Center for vSphere security groups which contain more than five expressions are not migrated. Examples of security groups that can be migrated: Up to 5 dynamic sets related with OR where each dynamic set contains up to 5 dynamic criteria related with AND (All in NSX Data Center for vSphere). 1 dynamic set containing 5 dynamic criteria related with OR (Any in NSX Data Center for vSphere). 1 dynamic set containing 5 dynamic criteria related with AND (All in NSX Data Center for vSphere). All member types must be the same. 5 dynamic sets related with AND and each dynamic set containing exactly 1 dynamic criteria. All member types must be the same. Using “Entity belongs to” criteria with AND operators is not supported. All other combinations or definitions of a security group containing unsupported scenarios are not migrated.

In NSX Data Center for vSphere, security tags are objects which can be applied to VMs. When migrated to NSX-T security tags are attributes of a VM.

Table 6. Security Tags

NSX-v Configuration	Supported	Details
Security Tags	Yes	If a VM has 25 or fewer security tags applied, migration of security tags is supported. If more than 25 security tags are applied, no tags are migrated. Note: If security tags are not migrated, the VM is not included in any groups defined by tag membership.

Services and Service Groups are migrated to NSX-T Data Center as Services. See Inventory > Services in the NSX-T Manager web interface.

Table 7. Services and Service Groups

NSX-v Configuration	Supported	Details
Services and Service Groups (Applications and Application Groups)	Yes	Most of the default Services and Service Groups are mapped to NSX-T Services. If any Service or Service Group is not present in NSX-T, a new Service is created in NSX-T.
APP_ALL and APP_POP2 Service Groups	No	These system-defined service groups are not migrated.
Services and Service Groups with naming conflicts	Yes	If a name conflict is identified in NSX-T for a modified Service or Service Group a new Service is created in NSX-T with a name in format: <NSXv-Application-Name> migrated from NSX-V
Service Groups that combine layer 2 services with services in other layers	No
Empty Service Groups	No	NSX-T does not support empty Services.
Layer 2 Services	Yes	NSX Data Center for vSphere layer 2 Services are migrated as NSX-T Service Entry EtherTypeServiceEntry.
Layer 3 Services	Yes	Based on the protocol, NSX Data Center for vSphere layer 3 Services are migrated to NSX-T Service Entry as follows: TCP/UDP protocol: L4PortSetServiceEntry ICMP / IPV6ICMP protocol: ICMPTypeServiceEntry IGMP protocol: IGMPTypeServiceEntry Other protocols: IPProtocolServiceEntry
Layer 4 Services	Yes	Migrated as NSX-T Service Entry ALGTypeServiceEntry.
Layer 7 Services	Yes	Migrated as NSX-T Service Entry PolicyContextProfile If an NSX Data Center for vSphere Layer 7 application has a port and protocol defined, a Service is created in NSX-T with the appropriate port and protocol configuration and mapped to the PolicyContextProfile.
Layer 7 Service Groups	No
Distributed Firewall, Edge Firewall, or NAT rules that contain port and protocol	Yes	NSX-T requires a Service to create these rules. If an appropriate Service exists, it is used. If no appropriate Service exists, a Service is created using the port and protocol specified in the rule.

Table 8. Service Composer

NSX-v Configuration	Supported	Details
Service Composer Security Policies	Yes	Firewall rules defined in a Security Policy are migrated to NSX-T as Distributed Firewall rules. Disabled firewall rules defined in a Service Composer Security Policy are not migrated. Guest Introspection rules or Network Introspection rules defined in a Service Composer Security Policy are migrated. If the Service Composer status is not in sync, the Resolve Configuration step shows a warning. You can either skip the migration of Service Composer policies by skipping the relevant Distributed Firewall sections. Alternatively, you can cancel the migration, get Service Composer in sync with Distributed Firewall, and restart the migration.
Service Composer Security Policies not applied to any Security Groups	No

Active Directory Server Configuration

Configuration	Supported	Details
Active Directory (AD) server	No