NSX-T on VDS

Prior to version 3.0, NSX-T could run only on its own virtual switch, the N-VDS. From version 3.0 on, we have the choice to run NSX-T on VDS in a vSphere 7.x environment. So, one short sentence with many facts, let’s list them:

  • Running NSX-T on VDS is a choice, we can still deploy N-VDS with NSX-T 3.x even in vSphere 7 environments. (we will come to the recommendation a bit later as this might change in the future).
  • To run NSX-T on VDS we need vSphere 7.x and vCenter as computer manager.
  • To run NSX-T on VDS we need NSX-T version 3.0 or later.

Why Back to VDS?

The question here is why does VMware want us to go back to VDS? and that is a fair question. As we know when NSX-T was introduces, one of the key differentiators of it (in comparison with NSX-v) was that it supports multiple hypervisors not only ESXi. So why we go back to the old model of supporting ESXi only? the answer is we are not. We can still run NSX-T on other supported hypervisors or Bare Metal servers by deploying N-VDS on them.There are many reasons VMware wants us to run NSX-T on VDS:

  • We know that physical NICs (pNICs) cannot be shared among virtual switches. So when we have to deploy an N-VDS in an host and we want to make it redundantly connected (which we always do), we need to dedicate at least 2 pNICs to our N-VDS. For hosts with only 2 pNICs (which we see a lot these days), this means: One host, One virtual switch, and that is the N-VDS. Therefore we need to migrate our infrastructure vmkernel interfaces to the N-VDS which is a challenge. Besides the difficult and disruptive migration, separating infrastructure and VM (overlay) traffic is almost impossible in this scenario. (see Figure 1-1)
  • We want 3rd party (automation) tools to recognise the virtual switch. What is that? well, as we know N-VDS related objects (portGroups) are owned by NSX and are represented as opaque objects in vCenter. Tools which read the configuration of vCenter mostly recognise only VSS and VDS objects (portGroups). So they do not recognise these opaque objects and therefore cannot deal with them.
  • Managing a single line of switch code (for VDS) is much more easier than separate lines if switch code. To fix a bug or add a feature with only VDS in the picture, there is no need to update/add codes in various places. Please note that we had VDS and then N-VDS Standard and N-VDS Enhances Path were derived from it.

Figure1-1

Once again, NSX-T can run only on VDS version 7 which requires vSphere 7. If we are not running this version the only choice is running NSX-T on N-VDS. Migration from VSS or VDS before 7.0 to VDS 7.0 is however possible via a wizard with rollback options which makes thing less risky.

What is different?

So now that we want to run NSX-T on VDS 7, we (can) have  VDS portGroups and NSX portGroups or better saying Segments.

We need to know that some objects are now “owned by vCenter” and NSX is “using” them, these objects are:

  • Uplinks
  • Switch MTU
  • NIOC Profile
  • LLDP Parameters

If we take a close look at these 4 objects we see that they are all  somehow related to physical NIC and are centrally managed by vCenter.

Tip: be aware that if you need one of these parameters different on different host, you need to create different VDS. It is not like before that you could apply different Transport Node Profiles with these objects to different Transport Nodes.

In Figure1-2 we see that because we needed to apply a Send only LLDP profiles to TN1 and a Send and Receive  LLDP profile to TNs 2 and 3, we had to create different VDS with different LLDP settings.

Figure1-2

It is important to know that the teaming policy for NSX Segments is still defined in NSX not vCenter.

Should we go for it?

Well, VMware’s recommendation is using VDS 7 in all new deployments (of course if you have vSphere 7.0 or higher running and if other products are compatible). The reason is that VMware wants to move towards using one virtual switch only in all vSphere environments.

Note: always consult VMware Product Compatibility Matrix when making your designs.

Sample designs

We can design the VDS for NSX-T in different ways depending on the number of NICs we have on our hosts.

  • Two-NIC Hosts: well obviously we have to let the VDS handle the traffic of all our vmk interfaces and overlay segments.

Figure 1-3

  • Four-NIC (or more) Hosts: if four or more NIC are available on out hosts we can nicely separate the infrastructure traffic (Management, vMotion, Storage, etc.) from the overlay traffic by connecting our vmk interfaces to one VDS (which does not necessarily need to be a VDS with NSX) and our overlay segments and TEP interfaces to another VDC (with NSX).

Figure1-4

Conclusion

Try to design your environment based in running NSX-T on VDS.

Always consult VMware Product Interoperability Matrices when creating your design.

Make sure that you separate infrastructure and overlay traffic when possible by creating different switches and assigning different pNICs to them.