NSX-T 2.4 – Unprecedented Enhancements

NSX-T 2.4 was released about 16 hours ago when VMware’s NSBU put this blog post out. Some pretty cool enhancements to NSX-T in this release have been introduced with some of the key ones being around application-centric SDN, Ansible orchestration, API consumption, data visualization and security, Day 2 and beyond operations (upgrades, troubleshooting and migration). IMO, this brings T just about at-par with V, probably surpasses it.

The version isn’t GA by the looks of it, since there isn’t a download available just yet:

I took about an hour and a bit to run through what’s available to learn up about this major release and here it is for your easy reading:

Increased manageability: A converged appliance cluster that slices the NSX Manager and Controller functionality across three nodes instead of the 1x NSX Manager appliance + 3x Controller cluster we’re used to in NSX-V. I reckon this enhances recoverability of the NSX Manager aspect of the management cluster in the sense that if you lost one cluster node, you could spin another one up and restore full management functionality (there’d probably be some more technical detail to the actual process but that’s the idea). Here’s a screenshot taken from one of the videos put out by the NSX technical product team:

Automation and orchestration: NSX-T can be programatically consumed 9 ways, I’ll save myself the trouble of writing them all up and instead present this screenshot taken from another of the TFD videos VMware have presented:

With 2.4, Ansible modules are now baked into the management cluster to get users rapidly working with creating and orchestrating logical networking constructs based on application needs (more on this in a bit). The DevOps Lead where I work at was pleased at this particular enhancement as it’ll allow him to further address his BU’s requirements around reducing cycle times and increasing speed to deliver applications.

It appears they are further addressing the API-first mentality pervasive through the industry and sorta stripping back the work needed with vRA (they’d probably be upcoming enhancements when they get around to the next release of vRA). Pooja Patel said – NSX is built with the API first and the GUI’s built on top. Rightly so!

An industry buzzword these days is a “Declarative Policy Model” that allows administrators to create policies based on application needs rather than on rigid security constructs. The idea is to use a .json file for a single unified approach to designing according to application requirements, there’ll probably be more information in the following weeks.

Operations: There are a number of significant improvements from an operational PoV Day 1 and beyond, some of them are:

1. Intuitive, clarified UI that logically steps administrators through to creating various bits and bobs – basically, workflow based wizards that make for seamless creation of new constructs based on application needs.
2. Troubleshooting is greatly enhanced via:
   1. Google-like aided/suggested search that predicts and fills in as you look an object up
   2. Save your favourite searches to reduce the time it’d take the next time you want to look the same things up
   3. Search via regex expressions allowing for combinations to computed and spat out (very much like vRealize Log Insight’s search mechanism we’ve come to love)
3. Data visualization is another one that’s seen a huge stride in improvement with rich dashboards that show administrators the state of any object in the SDN environment at a glance. The dashboards we’ve seen in vROps appear baked into the product now for a one-stop management pane.
4. IPv6 support for the overlay networking given the huge growth in IoT and mobile devices in a typical enterprise. The TEP’s are still at IPv4.
5. Traceflow‘s GUI is amazingly simple now and very clear. Easily see what’s going where, received by what, which host the source and destination’s at etc!

Scale: 2.4’s now going to scale tremendously:

1. Host count: Over a 1000 hosts per NSX management cluster
2. Routing: Apparently limitless route count via peering with physical devices (you should probably be using route summarization anyway)
3. Multi-protocol support was something I heard when Pooja presented her session, not quite sure if that meant OSPF for physical device peering. For now, I’d stick with believing BGP is the only supported protocol
4. High scale tenancy: That’s another term used in Pooja’s promo video, probably refers to the ability to create a realistically limitless Tier 1 Router count for tenancy at large scale.

Security: This is up there on everyone’s list these days. Pretty cool enhancements have been introduced:

1. Service insertion for E-W traffic. There are no details on what vendors will be supported.
2. Public domain whitelisting applied by the DFW which will allow VMs to hit public websites.
3. L7 context based firewalling is pretty cool.

The stock NSX -V security features such as context based firewalling, guest introspection have been around already and have been retained (this is almost needless-to-say information)

What’s yet unknown: There are a few things I’d personally LOVE to see are as follows:

vCenter Server count: I believe I read somewhere there’s a recommended max of 5 vCenter Servers that NSX-T 2.3.1 can attach to. 5’s a pretty low number for enterprises such as banks, service providers, government orgs etc. I’d want to know how many vCenter Servers can be attached to a single instance of NSX-T 2.4 Management Cluster.

Public domain blacklisting: Whitelisting is all well and good, but that’d mean enabling the same setting in the perimeter firewall too. What’d be better is if a large set could be whitelisted at the perimeter but the blacklist could be controlled programatically based on application needs or security guidelines within the SDN environment. This is one of those questions that I’ve been asked when designing and deploying NSX in the wild.

Multiple authentication sources: This is another one of those things a significant number of medium-large companies would have. There’s no information on whether NSX can now be RBAC’d via multiple authentication sources. Say you have two domains (one production and one dev/test), there’s a single NSX-T management cluster, how would you allow access to administrative accounts in security groups from different LDAP/AD domains for a well-structured, locked down and tightly controlled RBAC model? I’d personally want to see this. The counter argument would be – oh, if you’re having to get administrators to create the nuts and bolts for an application, you’re still doing it the old school way. Well – the news is most larger mobs don’t move at the same pace as the development in the industry and the constructs have to be manually created.

Azure/AWS tenancies and/or subscriptions: This is another big one for the companies out there looking at branching or bursting to the public cloud. There’s no mention if an organization can connect with their on-premises NSX-T 2.4 installation with multiple Azure/AWS tenancies and/or subscriptions. I reckon a number of public cloud customers would have a separate tenancy for production and dev/test or at least different subscriptions for the two types of workloads. I’d love to be able to get one instance of NSX-T 2.4 hooked up with multiple tenancies for that true single management pane for delivering networking and security for public cloud workloads in accordance within dictated guidelines.

Cross-site or VMConAWS NSX-T Management Clustering: While it’s all well and good for HA for the NSX Manager functionality, how about the clustering across sites (as in datacenters). With the high speed links between sites these days, the QoS and what not, I don’t see a reason why they wouldn’t have cross-site NSX-T Management Clustering. But again, no information on this yet. What about federation across NSX-T environments? I’d personally LOVE to see that going between on-premises NSX-T Management with the NSX-T instance in VMConAWS, I was actually asked this question a few days ago.

I hope most of this will probably get clarified/ironed out as the release notes and the eventual 2.4.1 version comes out. Hopefully someone in VMware’s technical product marketing team reads this post and comments. It’d be greatly appreciated.

All in all, an excellent release that should see an increase in the deployment of T in the companies that currently use V for their SDN needs. The future of SDN is BRIGHT and I’m so glad to be a part of it!

Note: the screenshots were taken from the announcement that VMware made yesterday and the TFD videos that were done. All the information listed in this article has been gleaned from the above resources only.