IP address not realized for VMs in dynamic security groups in NSX-T

Products

• VMware NSX

Issue/Introduction

Symptoms:

• Host(s) have been prepped using Security Only installation of NSX-T via the Quick Start menu.
• After a host is rebooted, the IP address assigned to the VMs, vMotioned to the host (after exit maintenance mode), are not seen in the security group, which the VM is a member of in the NSX-T UI. 
• DFW rules are not applied to that VM and the expected rule is not enforced against the traffic.
• The property 'com.vmware.port.extraConfig' is missing from the VM port when we run net-dvs and search for the port, as below:

net-dvs -l | less

• Then search this file for the VM's port number:

/<portnumber>

• The results looks like this:

com.vmware.common.port.volatile.status = inUse linkUp portID=67108901 propType = RUNTIME

com.vmware.common.port.volatile.vlan = VLAN 0

propType = RUNTIME

com.vmware.common.port.volatile.ptstatus = noPassthruReason=8, propType = RUNTIME

com.vmware.vswitch.port.swsec.enabled = true , propType = POLICY

com.vmware.vswitch.port.swsec.discovery = 0x 1. 1

propType = POLICY

com.vmware.vswitch.port.swsec.discovery.ipv6 = 0x 0. 0. a. 0. 0. 0. 1. 0. 0. 0. 3. 0 <repeats 3 times>

propType = POLICY

com.vmware.vswitch.port.swsec.security = 0x24.28. 0 <repeats 30 times>

propType = POLICY

Note: To find the VM port number, you can use net-stats -l

Environment

VMware NSX-T Data Center

Cause

This issue occurs when the switch port(s) used by the VM(s) are missing the 'com.vmware.port.extraConfig' properties.

An example of a switchport with the expected output, where the 'com.vmware.port.extraConfig' properties are NOT missing:

com.vmware.common.port.volatile.status = inUse linkUp portID=67108901 propType = RUNTIME

com.vmware.common.port.volatile.vlan = VLAN 0

propType = RUNTIME

com.vmware.common.port.volatile.ptstatus = noPassthruReason=8, propType = RUNTIME

com.vmware.port.extraConfig.security.enable = true ,  propType = CONFIG

com.vmware.port.extraConfig.vnic.external.id = 1645783971 ,   propType = CONFIG

com.vmware.port.extraConfig.opaqueNetwork.id = 98d23fa2-cc1b-496d-80c4-c9f718471b5a ,  propType = CONFIG

com.vmware.port.extraConfig.logicalPort.id = 1ff5ea57-1724-4399-891b-1f8a8a0e284d ,   propType = CONFIG

com.vmware.vswitch.port.swsec.enabled = true , propType = POLICY

com.vmware.vswitch.port.swsec.discovery = 0x 1. 1

propType = POLICY

com.vmware.vswitch.port.swsec.discovery.ipv6 = 0x 0. 0. a. 0. 0. 0. 1. 0. 0. 0. 3. 0 <repeats 3 times>

propType = POLICY

com.vmware.vswitch.port.swsec.security = 0x24.28. 0 <repeats 30 times>

propType = POLICY

Resolution

This is resolved in NSX-T 3.2.2.1 available at VMware Downloads.

Workaround:

You can use either of the following API to run against each impacted Transport Node to resync them:
Policy API:

POST /policy/api/v1/infra/sites/<site-id>/enforcement-points/<enforcementpoint-id>/host-transport-nodes/<node_uuid>?action=resync_host_config

Manager API:

POST /api/v1/transport-nodes/<node_uuid>?action=resync_host_config
 

Note: The Transport Node UUID can be found in 'System - Fabric - Hosts', click the 3 dot hamburger symbol and Copy ID to clipboard. Also, site-ID and enforcement-points are 'default'.

A sample API would look like this:
Policy API:

POST /policy/api/v1/infra/sites/default/enforcement-points/default/host-transport-nodes/a144b4b8-e7ee-4958-a4c5-dd648ece2acf?action=resync_host_config

Manager API:

POST /api/v1/transport-nodes/a144b4b8-e7ee-4958-a4c5-dd648ece2acf?action=resync_host_config