In-Depth

Windows Server 2012 R2's Hyper-V Networking Improvements

Microsoft's tweaks make it easier to fail over to a second datacenter when issues occur.

• By Brien Posey
• 01/04/2014

One of the biggest problems with traditional networking is it lacks the agility to quickly adapt to changing business needs. You may need to make major topology changes to a physical network. However, you're likely to discover that making those changes is complex, time consuming and expensive.

Virtual networking has made it easier to adapt to ever changing business needs, but the earlier versions of Hyper-V lacked the ability for networking to be adjusted dynamically. With the recent release of Windows Server 2012 R2, Microsoft is seeking to make Hyper-V virtual networking much more flexible and dynamic. It's using a new approach called software defined networking. Software defined networking should accomplish three things:

• First, it should support multi-tenancy and each tenant should be able to define its own logical networking topologies (and IP addresses) on a virtual network that resides on top of the physical network.
• Second, it should be able to manage traffic flows. This goes beyond simply establishing traffic forwarding rules. It also means having the ability to put in place bandwidth guarantees and bandwidth caps where necessary.
• Finally, software defined networking should be policy driven. Policies should be valid on both virtual and physical networks.

The new version of Hyper-V introduced in Windows Server 2012 gets you closer to these goals. However, Windows Server 2012 R2 introduces many additional new features, particularly with regard to the virtual switch.

Hybrid Forwarding
The virtual switch improvement that has received the most attention is a feature called hybrid forwarding. In Windows Server 2012 Hyper-V, Microsoft made the virtual switch extensible. This let third-party networking vendors write extensions that plug into the Hyper-V virtual switch. In some cases however, these extensions were disruptive because they attempted to handle traffic that really should have been handled by native code within the virtual switch.

The hybrid forwarding feature helps the switch differentiate between traffic that is Network Virtualization Generic Routing Encapsulation (NVGRE) encapsulated (a network virtualization protocol that tunnels multiple VLANs for hybrid cloud environments now in Hyper-V) and traffic that is not. This is important because it means that third party forwarding extensions can now seamlessly coexist with the native network virtualization code.

If a packet is NVGRE encapsulated, then the Hyper-V Network Virtualization (HNV) module built into the virtual switch can forward the packet. Non-encapsulated traffic can be forwarded by third party extensions you've added. As a result, the virtual switch can forward packets for both the physical address space and the customer address space. The customer address space is somewhat new to Hyper-V. It basically refers to a per-tenant address space in a multi-tenancy virtual environment.

Prior to Windows Server 2012 R2, you had to deal with the physical address space and the virtual address space. However, the underlying mechanisms left a lot to be desired when it came to multi-tenancy or being able to dynamically make architectural changes to the network.

The need for more agility and resiliency isn't unique to the virtual datacenter. Organizations have been forced to cope with problems such as multi-tenancy, address space reuse and subnet security for decades.

Prior to widespread adoption of server virtualization products such as Hyper-V, the mechanism of choice for multi-tenancy and address space reuse was VLANs. VLANs let multiple virtual networks exist on a common physical network segment. Even today, many organizations continue to rely on VLANs and have actually extended existing VLANs from the physical network to the virtual network.

Although VLAN's have been the go-to mechanism for quite some time, they do have their problems. For starters, VLANs are based on the use of VLAN IDs. This creates a theoretical limit of 4,096 VLANs. In practicality, the actual limit is often much lower. That's because the underlying networking hardware must support the VLANs, and many network switches support a maximum of 1,000 VLANs.

With these limitations, VLANs won't scale well enough to completely meet the needs of larger organizations. However, VLAN IDs aren't the only thing that have an impact on VLAN scalability. There's also the issue of subnets. VLANs are constrained to a single subnet. This severely limits what you can do with VLANs. Never mind the fact that VLANs can be difficult to manage.

So what does all of this have to do with software defined networking, a customer address space or Hyper-V? Well, more organizations are beginning to make the transition to a private cloud model for their datacenter. A private cloud is essentially a virtual datacenter that supports multi-tenancy and self-service provisioning. There are a number of benefits to private clouds including:

• Reducing the administrative burden
• Empowering end users and promoting accountability
• Offering automated VM deprovisioning mechanisms that can reduce costs by cutting down on the problem of VM sprawl
• Encouraging management to keep IT operations on-premises instead of outsourcing
• Significantly lowering the total cost of ownership over public clouds (when the total costs are examined over a period of five or more years)

In order for an organization to fully realize the benefits of a private cloud environment (or even a hybrid cloud environment), it must be able to get past the limitations imposed by VLANs. Specifically, you and your organization must be able to:

• Securely support multi-tenancy with the potential for overlapping IP addresses
• Moving VMs on an as-needed basis without being restricted by subnet boundaries
• Moving a VM without affecting its IP address

This is where software defined networking and the concept of a customer address space come into play. The idea is VMs, virtual networks and physical networks can be decoupled in a way that provides an unprecedented degree of flexibility. Specifically, enterprises with private clouds can provision their own virtual network topology and IP addressing scheme (the customer address space) with no regard for the underlying network architecture. Conversely, you can move VMs without worrying about needing to reconfigure the VM.

This decoupling is extremely beneficial for a number of reasons. In the past, moving a VM to a different datacenter (or in some cases even to a different location within the current datacenter) required you to provision the VM with a new IP address. Depending on how the environment was configured, assigning new IP addresses and updating DNS records could be a labor-intensive and potentially error-prone process. There are technologies that can automate IP address and DNS changes, however.

The bigger issue with IP address changes is that things like security policies and network services are often bound to IP addresses or specific subnets. As such, changing a VM's IP address may break things like firewall port rules, IPSec encryption or even the ability to access various services on the network.

Windows Server 2012 R2's Hyper-V Network Virtualization feature eliminates these problems. It lets your private cloud customers maintain their IP address usage, while also letting you relocate VMs as needed.

The new Hyper-V network virtualization architecture can be beneficial even in organizations that don't use multi-tenancy. Hyper-V network virtualization helps you live migrate VMs to Hyper-V hosts that reside in remote subnets, without having to make changes to the VM's IP address. This functionality could prove useful for redistributing host server workloads or for failing over to a remote datacenter.

Extended Port Access Control Lists
Another new feature in Windows Server 2012 R2 that has received quite a bit of attention is the Extended Port Access Control Lists (ACLs). The Extended Port ACLs let you create firewall rules that apply to the individual virtual NICs within a VM. You can create and manage these rules through PowerShell.

The main change with ACLs is they can now include the socket port number. This wasn't the case in Windows Server 2012 Hyper-V, where only MAC- and IP address-based ACLs were supported.

The extended ACLs provide a number of benefits, especially in multi-tenant environments. For starters, ACLs help you secure traffic flows even if they don't have direct access to the individual VMs.

The built-in logging capabilities are also a welcome addition. These have been primarily discussed as a diagnostic feature, but you can also theoretically use the logging features as a mechanism for implementing a system of chargebacks.

Creating ACL Rules
You can apply ACL rules at the user level or the application level. In either case, you must create the rules through Power­Shell. Thankfully, Microsoft makes this relatively easy to do.

The PowerShell cmdlet you would use for creating extended ACL rules is Add-VMNetworkAdapterExtendedACL. This has a rather convoluted syntax due to the number of different parameters supported. Fortunately, you can usually get by with using relatively few parameters.

To give you an example of how you might use extended ACL rules to enforce application security, let's consider a scenario with a server named Lab1. You want to create a set of rules that permits in-bound traffic over TCP Port 80, but blocks all other inbound traffic. You could accomplish this by entering the following two commands:

VMNetworkAdapterExtendedAcl –VMName "Lab1" –Action "Deny" –Direction "Inbound" –Weight 1
Add-VMNetworkAdapterExtendedAcl –VMName "Lab1" –Action "Allow" –Direction "Inbound" –RemotePort 80 –Protocol "TCP" –Weight 10

The first command denies all inbound traffic. The second command allows inbound traffic on Port 80. Notice the first command has a weight of 1 and the second command has a weight of 10. Commands with higher weight take precedence (a weight of 10 takes precedence over a weight of 1).

The previous example blocks all inbound traffic for a VM named Lab1. It then creates an exception for traffic coming in on Port 80. This is a blanket exception because the traffic's originating address isn't addressed. However, you can base rules around a remote computer's IP address. For example, you could modify the command allowing inbound TCP traffic on Port 80 so that traffic is only allowed from a specific host. Doing so involves adding the RemoteIPAddress parameter to the command. For example, such a command might look like this:

Add-VMNetworkAdapterExtendedAcl –VMName "Lab1" –Action "Allow" –Direction "Inbound" –RemoteIPAddress 10.1.1.10 –RemotePort 80 –Protocol "TCP" –Weight 10

Key Hyper-V Improvement
As you can see, Windows Server 2012 R2 Hyper-V offers some important improvements over previous versions of Hyper-V with regard to virtual networking. These improvements should go a long way toward making multi-tenancy more practical and toward making it easier to fail over to a secondary datacenter.