NSX-T Series: Part 4 – Use cases of Multi-Transport Zone

In this NSX-T Series: Part 4 – Use cases of Multi-Transport Zone blog, we will discuss what is the meaning of Transport Zone in NSX-T.
We will also discuss the use of cases when using multiple transport zones with NSX-T and how to design it.

But if you want to start from beginning you can refer my previous part of the Series:
NSX-T Series : Part 1 -Architecture and Deploy
NSX-T Series : Part 2 – Adding Compute Manager
NSX-T Series : Part 3 – Planning NSX VXLAN

What is Transport Zones

The transport zone on NSX-T is defined as a collection of nodes that can communicate with each other across a physical infrastructure over one or more interfaces ( TEPs). In NSX-T in further blogs, we will in detail explain the Host transport nodes and Edge transport node concepts.
In Transport node we have Host transport node and Edge transport node participates in the following transport zones:

>> Overlay: It is used as an internal tunnel between transport nodes which is VXLAN encapsulation.

>> VLAN: It is used between North-South connection between NSX-T Edge and Uplink connectivity to Physical routers. This will carry the 802.1Q tagged traffic from NSXT-Edge to Uplink routers.

• 

Properties of Transport Zone

There are following bullet points which we should keep in our mind for the Transport Zone:

1. A single transport zone can have all types of transport nodes ( ESXi, KVM, Bare-metal servers, and NSX Edge).
2. A transport zone identifies the type of traffic ( VLAN or Overlay ).
3. You have the option to configure one or more transport zone as per your requirements.
4. A transport zone does not represent a security boundary, but to segregate the traffic from vmnic level of ESXi we can design. ( Further on this blog we will explain with a use case)
5. Each transport node in a transport zone can be configured either as N-VDS or a DVS. ( N-VDS is supported on ESXi and KVM, but DVS 7.0 is only supported on ESXi)
6. Multiple VLANs can be added to a transport zone.
7. At most only one transport-zone can be connected via N-DVS
8. Multiple overlay transport zones with advanced datapath N-VDS if the transport node is running on an ESXi host, which is EDGE Node.

How to add Transport Zone

To add transport zone is a straight forward configuration which can be done through System >> Fabric >> Transport Zones >> Add
On this option, you can mention the transport medium ( VLAN/VXLAN)

Multiple Transport Zone

Multiple Transport Node in Same Transport Zone

If two transport nodes are in the same transport zone, VMs hosted on those transport nodes can be attached to NSX-T Data Center logical switches that are also in that transport zone. This attachment makes it possible for the VMs to communicate with each other, assuming that the VMs have Layer 2/Layer 3 reachability from NSX routing/switching features.

As in the following example, we defined the following Transport Zones where VXLAN is used for East-West Routing and VLAN used for North-South Routing.

Transport zones can be added as per the rack design, if it is collapsed design then all transport-zone should be added to ESXi and on EDGE as per the uplink mapping.
But if we have separate rack clusters for computing VM and separate for EDGE nodes, then in that case compute cluster need VXLAN transport zone only. And the EDGE node needs to be added with VXLAN and related VLAN uplinks. In the following example, we have added only the VXLAN Transport zone on Compute Cluster.

Multiple Transport Node in Different Transport Zone

If VMs are attached to switches that are in different transport zones, the VMs cannot communicate with each other. Transport zones do not replace Layer 2/Layer 3 underlay reachability requirements, but they place a limit on reachability. Put another way, belonging to the same transport zone is a prerequisite for connectivity. After that prerequisite is met, reachability is possible but not automatic. To achieve actual reachability, Layer 2 and (for different subnets) Layer 3 underlay networking must be operational. But the whole idea to make multiple transport zones depends on the requirement which could be :
1. In a multi-Tenant environment, if a dedicated tenant needs to separate the traffic from ESXi physical vmnic level ( Dedicated DVS for that Tenant). But FYI this is not way multi-tenancy is achieved in NSX-T.
2. If the Platform traffic need to separated which could be Management, NFV appliance mgmt, Automation layer, Monitoring, Backup, etc. ( This will discuss in detail in this blog )
3. If we want to separate the VM based traffic in that case general-purpose VM and secured VM will take a different path.

Use cases of Multiple Transport Zone

CASE 1 : Multi Tenant ( Dedicated DVS for Tenant)

In a multi-tenant environment, if some dedicated tenant needs to separate its own traffic for the purpose of guaranteed bandwidth from ESXi levels. Even there could be a scenario where the LAN cloud is separate from the current LAN cloud, wherefrom Computer Networking ex UCS there is the disjoint topology for VLAN segregation and the North-South Routing is on that LAN Cloud Domain.

CASE 2: Cloud Provider ( Management, NFV Mgmt, Monitoring, Service Layer)

In Platform of Cloud Provider, there are many platform related connectivity that should be always planned to be separated with Customer Data Plane which will be always good in the scenario of a Disaster scenario, Guaranteed B/W for Customers VM Data Plane.
>> 1. The general purpose of Platform could be the NFV VM Management Connectivity, where the vNIC of NFV solutions like Palo Alto, Fortinet, F5, AVI Management traffic could be terminated through a different LAN network.
>> 2. This separate network can be also used for the Automation layer in the most common language Service Layer for running any kind of Automation on the workloads.
>> 3. In some infra we use a separate network for VM Backup of the Customers VM most commonly with vendors like Rubrik, VeaaM, etc uses it.
>>4. This network can be also utilized for Monitoring, Patch, etc purpose also.

CASE 3 : General VM traffic and Secured VM Traffic

Suppose a single transport node contains both regular VMs and high-security VMs. In your network design, the regular VMs should be able to reach each other but should not be able to reach the high-security VMs. To accomplish this goal, you can place the secure VMs on hosts that belong to one transport zone named Secured-TZ. The regular and secure VMs cannot be on the same transport node. The regular VMs would then be on a different transport zone called General-TZ. The regular VMs attach to an NSX-T Data Center logical switch that is also in DC1-DVS. The high-security VMs attach to an NSX-T Data Center logical switch that is in the DC1-. The VMs in different transport zones, even if they are in the same subnet, cannot communicate with each other. The VM-to-logical switch connection is what ultimately controls VM reachability. Thus, because two logical switches are in separate transport zones, General VM and Secured VM cannot reach each other.

How Multi-Transport Zone Configured

In my lab environment I will configure multiple transport-zone by following steps:

1. Create Separate DVS for General and Secured VM and add the hosts where vmnic5 will be mapped to DC1-DVS and vmnic4 will be mapped to DC1-DVS-Secured.

2. Create NetworkBachelor_Secured Transport zone from NSX-Manager

3. You can plan for separate IP-Pool because if the underlying VLAN changes we can define related subnet with it.

4. Add the Transport-Zone on DVS : DC1-DVS-Secured ( This part will be explained on further blog)

Verification

• The separate VTEP will be configured from the related IP pool of the Secured Transport_Zone
  

Summary & Next Steps

In this post, we went through the concept of transport-zone of NSX-T and explained what scenarios will make you go with multiple transport zone, which from my experience will be very rare in small and mid-sized environments. In other words, even in NSX-V I always related One Transport-zone = vCenter DVS the same we can follow it here. As discussed above it all depends on the scenario the design can be planned accordingly. For further details, you can check on the VMware link.