NSX Transport Node Profiles (TNP) and Sub-Transport Node Profiles (Sub-TNP)

Transport node profiles (TNPs) are a way to consistently apply NSX configuration to vSphere compute clusters. TNPs define the transport zones (overlay and/or VLAN), VDS configuration, uplink profile, TEP IP assignment (DHCP or IP pools) and teaming policy uplink mapping to VDS uplinks. TNPs are applied at the vSphere cluster level and as such, they can’t be used to prepare standalone hosts or edge nodes. A TNP can have only one uplink profile. An uplink profile defines a single TEP VLAN. As such, a TNP can be used to prepare clusters for NSX if the hosts have L2 adjacency for the TEP VLAN. This was the case till NSX-T 3.2.2 and NSX 4.1

Starting NSX-T 3.2.2 and NSX 4.1, a new enhancement has been introduced to TNPs wherein we could define sub-transport node profiles (sub-TNPs) and sub-clusters to prepare clusters having hosts without L2 adjacency for the TEP VLAN. The common use-case is around stretched compute clusters across racks in an L3 leaf spine topology, which we will discuss shortly.

If you are interested to dive in a bit deeper on preparing clusters using TNPs and network mapping for NVDS, please check out one of my older posts below:

Preparing 2-pNIC Compute Clusters for NSX-T using Transport Node Profiles and Network Mappings

Now that we are on NSX 4 and NVDS on ESXi transport nodes are deprecated, lets walk through the changes in TNPs as well as the new sub-TNP feature below. We will discuss this through two scenarios:

Scenario 1 deals with a stretched vSphere compute cluster across three racks (AZ) that has L2 adjacency for the TEP VLAN
Scenario 2 deals with the same stretched vSphere compute cluster across three racks (AZ) but without L2 adjacency for the TEP VLAN. Each rack has it’s own TEP VLAN.

Scenario 1 : Using TNP on a stretched vSphere Compute Cluster with TEP L2 adjacency across availability zones

The below sketch illustrates a homelab topology with four (4) ESXi transport hosts in a vSphere stretched cluster spanning three racks with L2 adjacency for the TEP VLAN. The TEP VLAN is VLAN 1001.

VxDC01-C01-ESX01.vxplanet.int and VxDC01-C01-ESX02.vxplanet.int are on Rack 1
VxDC01-C01-ESX03.vxplanet.int is on Rack 2
VxDC01-C01-ESX04.vxplanet.int is on Rack 3

Compute manager (VxDC01-vCenter01) is already added and the registration and connection status is successful.

Now let’s prepare the compute cluster for NSX using TNP.

We will create an uplink profile that defines the teaming policy and TEP VLAN (VLAN 1001). The teaming policy we use is “Load balance Source” which will result in Active-Active TEP interfaces.

Next, we will configure the TNP. From NSX-T 3.2.2 and NSX 4.1, the menu option has changed. This setting will be now under System -> Fabric -> Hosts -> Transport Node Profile

Since we have DHCP relay agent configured on the ToR switches for the TEP VLAN, we choose DHCP as the TEP IP assignment mode.

And finally, the cluster will be prepared with this TNP.

The cluster preparation process is now complete.

Scenario 2 : Using sub-TNP on a stretched vSphere Compute Cluster without TEP L2 adjacency across availability zones

The below sketch illustrates the same homelab topology with four (4) ESXi transport hosts in a vSphere stretched cluster spanning three racks but this time, without L2 adjacency for the TEP VLAN. Each rack has it’s own TEP VLAN. Rack 1 is on TEP VLAN 1001, Rack 2 is on TEP VLAN 1004 and Rack 3 is on TEP VLAN 1005.

VxDC01-C01-ESX01.vxplanet.int and VxDC01-C01-ESX02.vxplanet.int are on Rack 1 (TEP VLAN 1001)
VxDC01-C01-ESX03.vxplanet.int is on Rack 2 (TEP VLAN 1004)
VxDC01-C01-ESX04.vxplanet.int is on Rack 3 (TEP VLAN 1005)

Prior to NSX-T 3.2.2 and NSX 4.1, preparing clusters for NSX using TNP was complicated in this scenario as it didn’t give options for multiple TEP VLANs, and thus required manual preparation of individual hosts in the cluster. This brings the below challenges:

It drifts from consistent host configuration using profiles
The configuration is applied on per host basis, and not to the cluster. Future addition of hosts to the cluster would require manual preparation of the hosts.

Now lets see how we can use TNP for this scenario using sub-transport node profiles and sub-cluster mapping.

A sub-transport node profile (sub-TNP) defines the NSX configuration for a subset of transport nodes in the vSphere compute cluster that need the same configuration. All transport nodes that require the same configuration (for eg: all compute hosts on a given rack) can form a TNP sub-cluster. When a sub-TNP is applied to a sub-cluster, sub-TNP configuration overrides the global configuration from the parent TNP.

In the above topology, we have two sub-TNPs:

Sub-TNP named “subTNP_vxdc01-c01-az01” applied to sub-cluster “vxdc01-c01-az01” on Rack 2
Sub-TNP named “subTNP_vxdc01-c01-az02” applied to sub-cluster “vxdc01-c01-az02” on Rack 3
The hosts on Rack 1 are not part of a sub-cluster, hence will receive the configuration from the global TNP. (This is just to show that without a sub-cluster, the global TNP configuration is applied)

Let’s create three (3) uplink profiles, one for each rack (AZ), that defines the teaming policy and TEP VLAN. The teaming policy we use is “Load balance Source” which will result in Active-Active TEP interfaces.

Uplink profile for Rack 1:

Uplink profile for Rack 2:

Uplink profile for Rack 3:

Next, we will configure the global TNP settings. Note that Rack 1 inherits the global TNP settings, hence we will configure global TNP with TEP VLAN 1001.

We will now configure the sub-TNPs for Rack 2 and Rack 3.

Now the TNP configuration is ready.

Next, we will configure sub-clusters for Rack 2 and Rack 3.

Let’s define the mapping of sub-TNPs to sub-clusters and apply TNP to the compute cluster:

The “Other nodes” tab lists the transport nodes that are not part of any sub-clusters and hence will receive the configuration from the global TNP. In our case, this will be Rack 1 hosts.