Let me start with a quote I wrote down 5 years ago (wow did time pass by).
IMO this quote is still correct (maybe I should have used network & security skills) and really changed the quality of services I can deliver within the IT field. My NSX journey startet at this time with homelabbing and learning NSX-v from the one and only fellow comdivision partner & friend Matthias Eisner.
NSX-v; NSX-T; NSX Datacenter; NSX Cloud; NSX Advanced Load Balancer; NSX Intelligence.
Woa woa woa ….. that’s a lot of NSX…. Remember; NSX is not a single product. NSX is a suite of network & security products fullfilling VMware’s dream: Deliver every network & security service in software.
NSX-v (or NSX for vSphere) has been the software defined networking solution for vSphere evolved from the product vCloud Networking & Security. We were able to to create software-defined VXLAN networks or software defined network services with edge services gateway in a simple manor & create microsegmentation around vSphere based virtual machines.
It was good but it was a product around vSphere and not a real network product (which made it easier for me to get started with it).
NSX-T was created as a different to become a real network product decoupled from the vCenter that not just supports vSphere Hosts, but also bare-metal devices (edge services with high throughput & availability demand; Windows & Linux Machines) & fully integrated with the de-facto standard for cloud native apps: Kubernetes.
I did a lot of consulting, architecture & implementation of NSX-v. Very often for the usage of the distributed firewall to create microsegmentation or within the service provider field with vCloud Director.
I have observed NSX-T since 2.X, I did the NSX-T Install, Configure & Manage class, I visted VMware’s elite partner livefire training and I always ended up with the opinion.
“It’s cool; it’s a lot to learn; it does not seem to be ready yet”
If a customer just want to have a distributed firewall & microsegmentation in place (more on that later) the architecture with NSX-v was quite simple.
You only needed a single NSX-Manager; you prepared the hosts properly and voila: without any further requirements you were good to go to utilize distributed firewall rules no matter to which network a VM was connected to (vSphere Standward Switch; Distributed Switch).
With NSX-T a new switch has been introduced, the NSX-T virtual distributed switch (N-VDS). The big problem here is, that any kind of NSX-t functionality (e.g you want only the distributed firewall), requires workload connected to the N-VDS. Either we have enough physical uplink to utilize a dedicated N-VDS besides the ‚regular‘ VMware switch or your needed to migrate all VMkernel ports and functionality to the ‚non-vCenter‘ managed distributed switch. For sure it works and can be done, but creates some kind of complexity.
NSX-T 3.0 combined with vSphere 7.0 and a virtual distributed switch upgraded to version 7.0 allows us to utilize the existing vDS for NSX-T. The N-VDS is deprecetad within vSphere from now on :). This situation simplifies certain customer requirements & implementations I had / would had so far with NSX-T.
Besides that the NSX-T UI and API needed certain times to evolve. With NSX-T 2.4 an additional API – the NSX-T policy API has been added to beeing able to consume network services in a more declarative way instead an imperative way (how it has been done before). What’s the difference? In the declarative way (trending topic in IT) you define the final state and the business logic behind your API makes sure that state is fulfilled. That has been a good improvement but leaded to the fact that the UI was representing the both APIs.
- The new policy-driven API function were shown as simplified UI
- The older management API functions were shown und the Advanced Networking & Security
Even in the UI that created confusion (typically in our field advanced is always better ;-). But certain things could only be done in the advanced UI, which outcome hasn’t been seen in the simplified UI, etc.
I gotcha; It is enterprise software; enterprise software is allowed to have some complexity – but hey – We are in the year 2020 :) I never really like the UI NSX-T 2.X due to that and certain weird UI behaviours (refresh problems; error codes; etc.).
First of all the new UI in NSX-T 3.0 seems to act fast & has removed the Advanced Networking & Security section.
NSX-T is the way to go nowadays. Not just as today NSX-v will be out of support in January 2022, but the NSX-T is becoming more and more a serious network product.
- NSX-T is the key element within VMware’s Kuberntes products (vSphere with Kubernetes & Tanzu Kubernetes Grid) – Backed-in / simple to operate network & security services into the container orchestration will be crucial in the future
- NSX-T is used for NSX datacenter (the world we know) and NSX Cloud (utilizing NSX functionality in the hyperscaler world like azure & aws).
- NSX-T support federation across multiple sites
- NSX-T includes Network introspection services
- NSX-T allows highest available throughput for North-South traffic with the Bare-Metal NSX Edge Networking services (including sub-second convergence during failures)
- …… and for sure all the features I would consider as basic nowadays -> microsegmentation, software-defined overlay networking with GENEVE
We are in the year 2020 and not 2015 anymore; the pure functionality of a distributed firewall will not convince customers anymore to invest heavily in licenses, support, knowledge and properly a migration (some of my comdivision friends like Tobias Paschek & Matthias Eisner already did NSX-v to NSX-T migrations; if you require those services for yourself – let me know).
Over the next weeks I will try to improve my knowledge about NSX-T 3.0; I will go through all layers (Infrastructure; L2-Segments; L3-L7-Edge Services; Security Services) and try to understand them properly. To learn it better I will try to summarize the knowledge & will publish it here on the blog – so stay tuned.