VMware Partner Exchange 2015 Recap and NSX Introduction

After a long week of pre-conference boot camp training, the “Big Game,” and plenty of sessions and meetings, as well as a visit (and escape!) to Alcatraz, I’ve returned from VMware Partner Exchange (PEX) in San Francisco. VMware certainly made some exciting announcements, including the much anticipated introduction of vSphere 6.0. You can learn about all of the details of vSphere 6 in this whitepaper and this video. Other significant announcements during the week of PEX included EMC’s introduction of their EVO:RAIL device, VSPEX BLUE, VMware VSAN 6 and Virtual Volumes and the VMware acquisition of Immidio and its user environment management software. 

Instead of rehashing all of the announcements that you can read all about in the preceding links, I’m going to focus on VMware NSX. I participated in the Advanced NSX Boot Camp in the days prior to PEX. NSX is often dubbed a “network hypervisor” for virtualized networks, but let’s dissect what that really means. It means taking concepts and features traditionally available only in physical network devices such as routers, switches, firewalls and load balancers and bringing them into the virtual world. 

You no longer need separate physical devices for many of these functions (aside from switching), each with their own, often complex, management interface or command line interface. Everything in NSX is managed via the vSphere Web Client, with command line interfaces only needed for things like packet capture and advanced troubleshooting. Just like with server virtualization versus physical servers, network virtualization provides capabilities and features that are simply not possible in a traditional physical networking environment. 

In order to demonstrate the power of NSX, I’ll demonstrate a real-world example of how it can be used. VMware Horizon (with View) offers a wide array of capabilities for end-user computing, but often relies on the configuration of underlying networking features to implement various security measures. With NSX, we can provide a secure demilitarized zone (DMZ)network for View security servers, load balancing between View connection and security servers, and firewalling between desktops and servers (or between desktops and other desktops). 

Creating a DMZ network often requires a physical firewall device as well as network switch configuration to support its deployment. With NSX, we start by defining a new logical switch to support our new DMZ network: 

NSX logical switches use Virtual Extensible LAN (VXLAN) technology to create secure isolated networks without requiring configuration changes to the underlying physical switches. The logical switch is automatically made available as a port group on the VMware vSphere Distributed Switch for use with virtual machines. We then create an Edge Gateway to handle routing into and out of the DMZ network:

The Edge Gateway interface IP addresses are used for routing as well as network address translation (NAT) to allow traffic selectively into and out of the DMZ network. NAT rules are then added to configure which ports and IP addresses are routed: 

Source NAT (SNAT) rules allow the traffic from the DMZ to route to the rest of the network, and Destination NAT (DNAT) rules allow traffic into the DMZ to specific destinations. Firewall rules then control which systems can communicate with each other, and on which ports: 

It is important to note that these firewall rules are not required to be based on traditional networking concepts such as IP addresses or subnets, but can also be based off of vCenter objects and NSX security groups. In this example, we used NSX security tags assigned to View security server and connection server virtual machines in the vSphere Web Client to identify what NSX security group(s) each VM should belong to. This essentially teaches NSX what the servers actually are, so it can firewall accordingly. 

 We’ve also defined firewall rules between the security servers group and the View Desktops resource pool object. Different types of desktops can be placed in different resource pools, allowing you to have different sets of firewall rules for each desktop type. The ports allowed through the firewall rules are defined using services or service groups, many of which are pre-defined in NSX for View and other common application services. 

Once the firewall rules are defined, it’s possible to pair the security servers inside the DMZ with the connection servers and to allow users to connect through the security servers, while preventing them from any access to the internal network except for the systems and ports they are allowed to communicate with. 

This sample from our demo lab environment is just a basic example that only scratches the surface of the full power of NSX network virtualization. Any application, not just View, can benefit from these capabilities. Other advanced features such as micro-segmentation and automated network security deployed via vRealize Automation can truly unleash the full power of VMware’s Software Defined Datacenter (SDDC) in your own environment. 

Contact an Arraya representative to learn more and be sure to follow us on Twitter @ArrayaSolutions.