VMware NSX was heavily talked about two years ago when VMware first launched it, but no one seemed to truly understand what it was or what it did. Since then there hasn’t been a whole lot of discussion on it and consequently, most people still aren’t fully aware of what it does and how it works. At a high level, NSX is a virtualized and distributed firewall and router, but with a special twist to it — it’s part of the hypervisor. This blog will seek to spell out why that matters and how it is different than any other virtualized router/firewall.
Everyone knows how normal routers work: all data that routes has to traverse all the way to the physical device and then back… which isn’t greatly efficient in a virtualized world. We’re just going to look at virtualized routers, to spell out their differences to NSX. There are a lot of virtualized routers available in the market. Any Windows or Linux VM can be turned into a router quite easily through some simple built-in configuration. However, those solutions still leave the router on a single host, in a VM. If I have VMs on other hosts that need to route, they have to traverse the normal network to get to the virtual router before they’re routed. In the below simple diagram you can see a VM routing to another VM within a host (the orange ones). The data flows to the virtual router and then to the other VM without ever touching the physical network at high speeds:
But what if VMs on the other host need to route anything? Now the path gets very complicated and imposes a lot of latency and unnecessary bandwidth.
There isn’t an easy way to fix this with standard virtualized routers. What NSX does, however, is embed the routing within the hypervisor itself. That means that it can always intercept and route things internally as needed so the default gateway for the VMs can live on multiple hosts at once. If they need to route to other non-VM environments they will still have to use the edge services component (a common next hop gateway), but this can greatly facilitate network access locally on all hosts without ever having to hit network gear to route between VMs on the same host.
This is also huge for firewalling between VMs. Let’s say Network 1 is the DMZ and Network 2 is the internal network. The two VMs may need to talk to each other a lot (app server and database) but we need to make sure all of that traffic is inspected and validated at a firewall before it traverses. NSX again pulls that firewall functionality (up to layer 4) into the hypervisor itself, so as the routing happens locally inside the ESX host, ACLs can also be validated to see if the traffic is allowed. This improves the speed of security greatly, because it prevents a lot of north-south traffic in the network to get to a physical firewall appliance. Further, defining these firewall rules is very easy, because it uses the objects already defined in VMware (a VM, a network, a NIC, etc).
In short, NSX is a huge boon for customers who have a LOT of virtualized traffic that needs to route between each other, as well as a lot of security concerns. NSX can save a massive amount of uplink traffic, as well as physical network traffic, and only send to the external network what truly needs to make it there.