NSX is like a Swiss army knife of software defined network and security capabilities. The scope of all the things NSX can do can be quite overwhelming at first glance, and how it gets implemented and the use cases for it may not be immediately apparent. I think it is important to know what problems you want to solve and the cost associated with solving them. Here I will outline 5 use cases where deploying NSX will save time and money compared to other solutions.
Use Case 1 – Microsegmentation
Microsegmentation has been one of the top used cases for NSX from day one. It allows you to ensure that only specific hosts can communicate with each other based on rules. An example of why this is important is to use the comparison of a bank. Banks have lots of money and other important items in them that are only accessible to certain people. Person A cannot access the money, or the safety deposit box of person B. Person A should not even know there is a person B, or who they are. Security for many organizations is often similar to a lobster shell. A hard exterior with a mushy and tasty interior. Or like a large single room warehouse with all data sitting on pallets, waiting to be taken. Once someone is past the shell, or the doors, they have the full ability to do as they please. Microsegmentation creates firewall rules based on the requirements of applications to communicate with each other. Are there any public facing resources in a DMZ? How can you ensure that one server cannot access another server on the same network? You could create many VLANs with only host in each VLAN and then have your legacy firewall manage the access control lists. Or you could use a software-based firewall on each of the servers, like iptables, firewalld, or the Windows Server firewall. However, those all have their drawbacks. Here are some instances of microsegmentation:
1) One host per VLAN model with external firewall providing ACLs
First off, this is crazy; no-one does this. However, it would achieve the objective of microsegmentation. So, you can think of this as a thought experiment. Benefits:
- Provides north-south security between hosts based on centralized rules that simulates east-west security
- Very complex to manage for even a small network
- Limited to 4094 hosts due to VLAN limits
2) Software-based firewall
This is the most common interim solution for environments that have not moved to a microsegmentation solution. Benefits:
- Provides basic east-west security between hosts.
- Complex spreadsheets need to be maintained to know what hosts can access other hosts and based on which rules.
- Management of this would devolve very quickly to an allow any-any rule, thus nullifying any perceived benefit.
- Centralized management would require a configuration management system such as Puppet and it would be difficult to manage and maintain for network and security teams.
- There would be no insight into the traffic patterns, what it passes or what is being blocked, other than from logs. So, you would need a log management system with detailed search patterns to manage the environment as well.
This is where NSX really shines. You simply tag the server with the type of role it has, ie: web, DB, file-server, custom app, etc. Then create a rule that says for instance, all web servers can access DB servers on a defined port, and nothing else. One rule replaces many rules on many servers. What if the web server is being decommissioned or going in to maintenance? Simply remove the tag that says it’s a web server. No rules need to be modified. What if you have an application that communicates with other hosts, but you have no idea what ports or protocols it uses? Easy, run a tool called vRealize Network Insight, and it will scan the hosts and tell you what hosts, protocols, and ports it speaks. Even better, it can be used to create your rules in NSX with a couple of clicks! Here is the path from zero to microsegmentation:
Use Case 2 – SD-WAN
Software defined wide area networking is a means of reducing cost and complexity for inter-office and data centre transit. Here is a synopsis of the problem.
- Offices need to communicate with each other. This can be for VOIP or teleconferencing, data replication, shared applications, remote management, etc.
- Offices need access to data centre resources
- Offices need access to SaaS applications
- Remote users need access to SaaS, data centre, and branch office resources
The solution for many organizations has been one or more of the following:
- Private MPLS networks to connect all locations
- IPSEC VPN connections over public internet
- Site to site dark fibre
- Data centre uplinks to internet
- Data centre direct connect to cloud providers
- Client VPN connections to data centre
NSX SD-WAN solves all of these problems. Think of it as a means to utilize multiple connections at the edge, then apply rules to steer traffic to get the best quality of experience (QoE). You get high-performance and secure connectivity to branch sites, enterprise data centers, cloud environments, and SaaS offerings. With SD-WAN, you reduce costs through the following means:
- Reduce the bandwidth requirements of expensive dedicated links and achieve greater availability and performance by using multiple commodity connections like cable, DSL, LTE, and public fibre
- Centralized configuration reduces deployment time and costs. Ship out physical appliance or deploy VM and turn on. All management is done centrally
- No specialized equipment required to deploy at branches
- Subscription and pay-as-you-go models reduce capital costs and provide an immediate ROI
Use Case 3 – Layer 2 Extension and Data Centre Bridging
If you have applications that have static IPs and you want to increase the availability across multiple sites, then you have a few options.
- Scale out active / active – Refactor the application so that it can scale out sub-components and use server load balancers and global load balancers to abstract the actual IP addresses spanned across multiple sites
- Active / passive – Have a DR site and a runbook that includes reconfiguring the IP addresses of all components to operate at the DR site in the case of a failover
- Implement a layer 2 extension across sites to have a single network that can accommodate movement of servers between them with no IP configuration changes required
If you opt for a layer 2 extension, then there are 3 transport options. a) Dark fibre This is very expensive and not a strategy for long distances. It will work for inter-building and campus environments in the same city. b) L2VPN over MPLS This can be quite costly and is metered based on utilization. Dedicated equipment is required, and all endpoints reside on a single service provider network. c) IP based solutions This can use any internet capable connection and applies an overlay to encapsulate data. Proprietary overlays like Cisco OTV require dedicated vendor equipment that can support it at each endpoint. VXLAN is a standard that is open and is used with VMware NSX. There are no hardware requirements and it is completely software defined. An NSX Edge appliance used to establish SSL VPN connections between sites, then layer 2 is over layered. This can be used for sites that have NSX deployed, or on other sites that simply need a layer to bridge to an NSX site. Often this is used for seamless migrations from remote sites to data centre’s. If two or more sites have NSX deployed with VXLAN, then you can utilize all of the benefits and capabilities of the NSX solution, including distributed firewalls, load balancing, centralized security policy management, etc. NSX layer 2 VPN connectivity allows you to migrate VMs between sites without IP changes, increased site availability, and recovery options. It does this entirely within software, with no propriety hardware requirements. This lowers the cost and time to deploy stretched layer 2 capabilities with no dependency on the network services provider.
Use Case 4 – Load Balancing in a VDI Environment
When you are deploying a VDI environment, you want to ensure scalability and high availability of resources. This requires load balancing of components like connection servers, unified access gateways, and security servers. Generally, your options for this are as follows:
- Do not load balance these components until you reach a certain number of users and availability requirements that demand it.
- Implement a hardware load balancer, like an F5 BigIP LTM or a Citrix NetScaler.
- Implement a load balancing virtual appliance. The cost is generally similar to the equivalent vendor hardware appliance but is more easily deployable.
- Deploy NSX and use an Edge Services Gateway appliance for load balancing.
Here’s the cool thing about using NSX for load balancing with Horizon. You can license NSX on a per user basis. This reduces the cost for 100 users by 50% when compared to a hardware, or virtual appliance from F5 or Citrix. Now you don’t just get the load balancer for a fraction of the cost. You get the full product, allowing you to do microsegmentation between virtual desktops and RDSH sessions. This also gives you identity-based firewalls, so some users that connect to virtual desktops or sessions, can access resources on the network that others cannot.
Use Case 5 – Network Blueprinting, Automation, and Orchestration
When deploying applications from a catalog in vRealize Automation, CPU, memory, and storage are not the only resources that need to be defined. Perhaps the applications deployed need to be isolated or require security tags to be applied so they adhere to predefined policies or maybe load balancers need to be deployed. All of these functions are available when you combine NSX with the blueprinting capabilities of vRealize Automation. What if you want to get the benefits of automation with NSX but with the smallest footprint possible? Then you have a few other options that you can leverage as well. If you treat infrastructure as code, then you can make use of declarative platforms such as Puppet and Terraform. Both have the ability to integrate with the NSX manager using modules or providers, and with a few simple lines of code you can deploy environments of great complexity. Or you could even take it one step simpler and use PowerNSX. PowerNSX is a PowerShell module that abstracts the NSX REST API into a set of easily used PowerShell functions. There is even a PowerNSX script available called “Build NSX from Scratch”, which will stand up a new NSX environment in under 10 minutes. VMware NSX has a wealth of capabilities that I have only briefly touched on with these five use cases. There are many others from both a security and network connectivity perspective. As more diversity in technology strategies emerge, there will always be a need to connect and control objects, assets, and sites. VMwares network and security virtualization portfolio consists of NSX Data Centre, NSX Cloud, AppDefense NSX SD-WAN, and NSX Hybrid Connect. Getting started with NSX is pretty easy, and depending on your use-case, it can even be deployed in a day. However, to get the best use out of it, your use cases should be mapped out and the strategies for implementing them defined.
Looking to get setup using NSX?Reach out to a Scalar infrastructure specialist.