Hyper-V networking strategies for a software-defined world

Software-defined networking can help you address tough Hyper-V networking challenges, but only if you understand the basics and can leverage it.

Software-defined networking will be one of the most important technologies for IT pros over the next five years.

Now is the time to learn some of the basics of software-defined networking, especially as it relates to Hyper-V networking.

Software-defined networking is designed to address two big challenges that network administrators are facing today. The first of these challenges is multi-tenancy. Obviously, service providers have multi-tenant networks, but even enterprise-class networks are becoming multi-tenant as more and more organizations adopt private cloud models that allow self-service provisioning of virtual machines (VMs). Administrators need a way to prevent tenants from being able to access each other's networks and to keep them from accessing the core network infrastructure.

The other challenge is the fact that in many organizations the data center is no longer confined to four walls. Traditional networks are giving way to hybrid clouds or are being linked to geographically separate failover data centers.

Software-defined networking is designed to address both of these challenges by creating a series of logical networks on top of a physical network. In some ways, this approach is nothing new: Virtual private networks (VPNs), which have existed for well over a decade, use a similar technique to securely tunnel private data across the Internet.

From the standpoint of their basic features, software-defined networking works a lot like a VPN. Both technologies use packet encapsulation as a way to route traffic across a physical network. This encapsulation allows the packets to remain private and to coexist with other virtual networks. In the case of software-defined networks, this means that client address spaces can remain separate and private (which is important for multi-tenancy) and it means that a logical subnet can span multiple physical networks.

Separate address spaces make this architecture possible. At the host level, IP addresses are treated as provider addresses. Provider addresses are the IP addresses assigned to individual Hyper-V hosts. The other type of addressing used is consumer addresses, which are assigned on a per-VM basis. Because each consumer or tenant has its own unique virtual network that is defined at the software level, it is perfectly acceptable for multiple tenants to use the same consumer addresses. In fact, tenants can even use overlapping MAC addresses because the software-defined networks are kept completely isolated from one another.

Of course, creating virtual networks that are completely isolated from one another is one thing, but in the real world, the systems residing on virtual networks often need access to outside networks. Likewise, external clients need to access the services provided by the machines on a virtual network. Microsoft's solution is to use a Network Virtualization using Generic Routing Encapsulation (NVGRE) gateway. The NVGRE gateway performs several important functions.

First, the gateway provides routing capabilities. Routing is necessary for communicating with the physical network from the virtual network. Keep in mind that a single tenant will likely have VMs on multiple Hyper-V hosts. The NVGRE gateway is not necessary for communicating between VMs residing on different hosts; it is used only for facilitating communications between physical and virtual machines.

This raises the question of how VMs residing on separate Hyper-V hosts are able to communicate with one another when software-defined networking is used. When a VM needs to communicate with a VM that resides on a different host, Hyper-V needs to know where to send the encapsulated packet. The solution is to use System Center Virtual Machine Manager to manage the various Hyper-V hosts. Doing so allows Virtual Machine Manager to create and maintain a Hyper-V networking lookup table that keeps track of which VM resides on which host. Since each individual host has a relationship with Virtual Machine Manager, it becomes possible for any host to locate any VM.

An NVGRE gateway also acts as a Network Address Translation appliance, exposing application servers to the Internet even though those services actually reside on virtual servers inside a software-defined network. This allows VMs on software-defined networks to act as public-facing Web servers or to provide other Internet-facing services.

As you can see, software-defined networking is an extremely important concept, especially as legacy networks give way to private or hybrid clouds. Keep in mind that although Microsoft has its own software-defined Hyper-V networking mechanisms in place, the concept of software-defined networks and NVGRE gateways are not proprietary Microsoft technologies but industry standards.

This was first published in December 2013

Dig deeper on Network virtualization

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

Related Discussions

Brien Posey asks:

Will software-defined networking find its way into your data center soon?

0  Responses So Far

Join the Discussion

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchVMware

SearchWindowsServer

SearchCloudComputing

SearchVirtualDesktop

SearchDataCenter

Close