With my background in Networking and Virtualisation, VMware’s NSX is something which interests me deeply, as such I’ve attended a handful of sessions online, and also at the UK VMUG where Chris Whal presented on the subject.
Here’s my own interpretation of this new technology.
What is NSX?
Its software-defined networking, you don’t need to buy any hardware to implement it, although you do need a running VMware environment.
We take the functions currently held in the network, on switches, routers and firewalls, and move them into every ESXi host in your network, meaning within each host, you have the following;
- Layer 2 Switching
- Layer 3 Routing
- Logical Firewall (Layers 4 – 7)
- Logical Load Balancer
- VPN capabilities
- A RESTful API (Meaning you can tie into cloud/bespoke services)
OK, just take that in, you get all the above services, in each and every host.
Why would you want to do that?
Two reasons, to reduce the load on your network, and create better security policies on your network. There are also other reasons, but for me, these are the two main ones.
How does it help?
So cheeky taken from this fantastic VMware Blog post by Brad Hedlund, the two screenshots below, show the flow of traffic for two VM’s that are on the same host.
You’d think that the traffic wouldn’t leave the host, but it does. However when an NSX logical Switch is deployed, this looks at the traffic, and keeps it within the host.
What about to another host? Obviously this traffic has to leave the host, but depending on your network structure, is it really the best route it’s taking to do this? See below, imagine between the Switch and Fabric A, there is 5 hops. Think of the latency, then think the traffic is coming from one SQL server to another. During those 5 hops, if one of the switches then has a “hiccup” due a firmware bug or overloading of traffic, you’ve hit a possible point of failure.
By implementing NSX, you can reduce this chance of a point of failure.
Each host will run a logical switch, and be aware of the other hosts on the network. They will all be connected by a common “Transit VLAN” utilizing VXLAN encapsulation. The data will be encapsulated, sent to the other host on the common VLAN, de-encapsulated by the receiving host, and then passed onto the VM.
Next up is the firewalling capabilities. Each and every VM will have a Firewall places at its Network card, meaning you can control traffic before it hits the host, never mind the copper wire of the network.
This firewall is capable of looking at Layer 3-7 services, we are all aware of what a firewall does. So here’s a scenario you can achieve with the NSX Firewall.
A quick example
You have a sales database running on the VM called “SALES-SQL”, this is access through an application on port TCP 8999, which is ran from the client desktop. You can set the firewall to only allow traffic to that VM from the client desktop subnet range on port TCP 8999, which is pretty standard, but going further, you can restrict that traffic to only come from certain Active Directory users!
Meaning, if you have another user on the network trying to access this server using, for example SQL Management Studio, they would be blocked due to;
- Accessing the server on the wrong port
- Not been the correct AD user, or within the correct group
Ok, but why is that special?
Now, your thinking yes, but we can do this within the OS itself, why is this special?
And that’s because its done before you hit the OS!!! Remember the heartbleed issue, that was down to exploiting the application to give a response. With NSX, you don’t get to speak to the OS unless your verified to begin with. Reducing the chance of a hacker or so forth from accessing your system and having the chance to exploit it!
So what happens when you move that VM around your datacenter? That’s obvious, its VMware!
The policies move with it! Even in a DR event, and the IP address of the VM changes, the policies will remain.
There is a lot of scope with this product, especially for those with a proper datacenter environment. Those who do not have a proper datacenter environment, i.e a LAN Segment for users hanging on the same subnet, may struggle to implement the full feature set.
However, I plan to write more on NSX in the next few months, as I study more and hopefully take my VCP-NV exam. You can learn more at this VMware NSX Walkthrough page as well, rather than wait for me to produce some more information.