What is our primary use case?
The Environment was an active-active Tier-0 multi-site deployment (primary/secondary).
It contained compute and management clusters, and a small number of transport ESXi nodes (between five and six) v6.7u2, vCenter 6.7u2, AD.
The primary use case was to implement micro-segmentation and route production workloads through NSX-T via BGP. Our customer needed assurances that BGP routing within NSX-T would be efficient.
We implemented a very simple architecture and setup site with one NSX Manager as the primary source. This was a financial customer, thus security was the main item.
We had to explain to the customer that NSX-T deployment and micro-segmentation were two different projects explicitly.
How has it helped my organization?
NSX-T has allowed us to implement micro-segmentation in the customer's environment seamlessly (zero-trust). We have also looked at deploying Tufin or Gardicore, ReSTNSX as alternative tools. The Environment was an active-active Tier-0 multi-site deployment
The organization was able to begin scaling out its production workloads and clusters.
From a security standpoint, the customer was able to better secure critical workloads while routing L2/L3 worked normally, giving them more confidence that they would be ready for any potential security incident mitigation or outage (DR).
What is most valuable?
The most valuable features are:
- N-VDS Geneve encapsulation L2/L3
- Less need for the VM to hit the TOR switch to communicate with VMs on the same ESXi host/segment (logical switch)
- Micro-segmentation capabilities/tagging
- NSX-T dashboard/compute usage across the configuration allows a quick view
- The NSX-T configuration screens are fairly easy to navigate but they might need to simplify them a bit in future versions.
- Very extensive detailed configuration items can be set in Uplink profiles to better map pNICs
- Edge TEP and Host TEP tunnel config and troubleshooting is much more understandable and verifiable
What needs improvement?
Traffic flow introspection topology visibility is definitely needed because at the moment, NSX-T lacks in this area.
A hardware scan of the ESXi host for possible incompatibilities should be added to NSX-T/vSphere, as it would allow us to know in advance, for example, if a pNIC is not compatible with a version of vSphere before moving forward with an NSX-T deployment.
It needs a better, integrated migration tool. Something like RestNSX with more elaborate capabilities from a troubleshooting perspective and pre-migration perspective would be an improvement.
For how long have I used the solution?
I have used this solution version most recently, as it has not been out that long.
Many companies are moving to v3 and v3.01
N-VDS will be depreciated in newer versions and integrated within the standard VDS
What do I think about the stability of the solution?
From a recoverability standpoint, if designed correctly and perhaps if VMware SRM is integrated with NSX-T, it would help the stability of workload availability.
From a routing perspective, NSX-T must be designed for redundancy with cross/overlapping uplinks from the edge nodes to your L3 upstream devices. Routing will be more reliable with default routes in place. Hardware compute and compatibility with the solution is critical for good communication via the nsx overlay network. Overall this solution is very scalable
What do I think about the scalability of the solution?
NSX-T is extremely scalable as a solution. Make sure that you plan your IP pools accordingly in advance if you plan to add many transport ESXi nodes in the future.
How are customer service and technical support?
VMware Global support for NSX-T/V is exceptional.
Which solution did I use previously and why did I switch?
We have never used any other solution. NSX is the premier product in this space.
How was the initial setup?
The initial setup will go smoothly if the design of the solution was done correctly.
NSX-T can be complex if the discovery phase was not granular enough.
What about the implementation team?
We implemented it with an in-house team.
What was our ROI?
Customers will better be able to determine ROI once they have been running the solution for a year or so. How much they will have from the Capex perspective will have to be calculated.
What's my experience with pricing, setup cost, and licensing?
My advice is to make sure that you properly scope the project from both hardware and network requirements. NSX-T can be complicated if it is not designed correctly.
Which other solutions did I evaluate?
Some customers are evaluating Gardicore vs NSX.
Gardicore is a great tool for micro-segmentation only. It can fill in many gaps that NSX-T misses with its native micro-seg capabilities.
What other advice do I have?
An NSX-T solution requires a solid understanding of routing/switching, IP pools, local egress, and solution design to be successful. It takes a team of both VMware and Cisco folks to collaborate to get it done right the first time.
As a customer, make sure you are hiring the best resources.
Which deployment model are you using for this solution?
Which version of this solution are you currently using?