If you’ve read any of the posts from my Working with NSX series, you may have noticed that I’m using NSX 6.0. Specifically 6.0.3 for much of it, although my lab has been on 6.0.5 for a reasonable period of time. This is going to once again change as VMware has announced the release of NSX version 6.1.

According to Brad Hedlund, whom I have blatantly stolen the slide graphics from in this post, the newest version of NSX will be available very soon, likely this week or the week after. The 6.1 build of NSX is intended for vSphere hypervisor deployments and is often referred to as NSX-v or NSX for vSphere.

Let’s dive into all of the various enhancements being announced for NSX-v first, then I’ll cover the updates for NSX-mh, the multi-hypervisor version, towards the end.

Contents

DHCP Relay

Not all subnets have a DHCP server directly attached in the same network. Historically, you can solve this challenge by configuring a DHCP Relay address, sometimes referred to as DHCP Helper, on a network device that forwards DHCP requests on behalf of the client to whichever DHCP server you wish. My experience with DHCP Helpers come from doing a lot of VoIP phone deployments where ranges of devices needed option codes from specific sets of DHCP servers, but you may have worked with this technology for servers in different trust zones or subnet groups.

The latest release of NSX will also have the ability to include DHCP Relay details on the Distributed Logical Router (DLR). That’s one less thing to worry about if looking to use NSX routing features for your software defined network.

Two Stage Equal-Cost Multi-Path (ECMP) Support

I find this particular update super cool. NSX now has the ability to support ECMP between the Distributed Logical Router (DLR) and the NSX Edges, and from the NSX Edges to the physical network. You can use whatever routing you’d like – static, OSPF, iBGP, or eBGP – and the results are the same. As you can see in the slide below, this is limited to 8 ECMP paths, which I think is still spectacular.

This opens up a lot of new use cases in which bandwidth is better utilized by way of multiple NSX Edges and their respective uplinks. I was informed that stateful traffic, such as using the Firewall feature on an NSX Edge, is not a candidate for ECMP.

Layer 2 VPN Enhancement – Enterprise Migration

NSX has already been able to form a Layer 2 VPN (L2VPN) across data centers, but was formerly limited to a single VLAN / VXLAN. Now, you can trunk a variety of VLANs or VXLANs between data centers using the L2VPN feature on your NSX Edges. You can also mix the traffic – going from VLAN on one side to VXLAN on the other side – if that makes sense, such as in this enterprise migration scenario below. A very slick way to do layer 2 extension across data centers in software. Note that both data centers would be running a cluster of NSX Controllers, typically 3 per side.

Keep in mind, too, that because the NSX fabric is aware of where the virtual machines live, there’s a lot less headache around issues like tromboning or broadcast suppression. The VTEPs (VXLAN Tunnel Endpoints) handle much of the filtering for these types of scenarios based on tables that are distributed via the NSX Controllers.

Layer 2 VPN Enhancement – Hybrid Cloud

Another option discussed by Hedlund was the idea of a one sided NSX deployment for tenant onboarding for a hybrid cloud. In this particular use case, only one of the two data centers is running NSX. Only the NSX data center would be running NSX Controllers, which is typically 3 in number for quorum reasons. By deploying a “free standing” NSX Edge in the non-NSX data center, and connecting it via L2VPN to the NSX data center, an SSL VPN Tunnel can be crafted to pass along a L2 segment or provide routing services between sites.

The tunnel can connect VLAN to VXLAN or VLAN to VLAN.

Load Balancing Enhancements

Every NSX Edge has the ability to provide additional services, such as the L2VPN example above. Another service available is load balancing. I’ve worked with two primary use cases: in-line load balancing and one-arm load balancing. It’s a very handy way to provide some relatively simple load balancing policies – round robin, source IP hash, least connection, and URI – to applications that can take advantage of the feature.

In addition to a long list of supported protocols and methods available in the previous release, NSX 6.1 includes the ability to load balance UDP and FTP. A full list of features can be found below:

F5 Integration with NSX

NSX 6.1 introduces the ability to integration with F5’s BIG-IQ solution to provide some more robust load balancing solutions (among other things). To start, today’s integration is limited to BIG-IQ and BIG-IP Virtual Edition (VE) appliances. In the near future, NSX will also integrate with the physical BIG-IP appliances.

When enabling the load balancing service on an NSX Edge, there’s a check box called Enable Service Insertion. As long as you’ve registered the BIG-IQ solution with NSX, a new option will appear to choose the F5 as your service definition. From there, you run through the typical NSX workflow by configuring pool members for your nodes and then build out the VIP (Virtual IP). The F5 uses familiar iApps that you all know and love and the configuration is pushed up to the BIG-IP VE. Snazzy! 🙂

Firewall Enhancements

The last thing I’ll cover with NSX-v are the list of firewall enhancements. They are:

Firewall “Reject” Action
Troubleshooting and Monitoring
- Advanced Filtering of Rules
- CPU/Memory Thresholds
- IPFIX Support in DFW (Distributed Firewall)
Provisioning
- Combined Edge and DFW Management
- Network oriented Service Insertion (NetSec Partner Redirection)

Additionally, I found the micro segmentation use case beat to death, but I did really enjoy these two examples. First, let’s imagine there’s a firewall located somewhere in the network. We also have a pair of servers that are on the same subnet and want to pass traffic to each other. Without some trickery, they can chat over layer 2 with one another as shown below:

Next, we’ll add NSX’s Distributed Firewall (DFW) to the mix. Because the firewall is on the vPort that the virtual machine connects to, a firewall rule becomes not only possible, but rather trivial to do.

NSX-mh 4.2 Release

The multi-hypervisor version of NSX also received a bit of love and is now at version 4.2. This is a minor “dot release” update for NSX-mh. The list of new hotness is below: