This article is Part 8 in a series of articles of the "Top 31 Favorite Features in Windows Server 2012" with my fellow IT Pro Technical Evangelists.  Be sure to follow them on Twitter and check out their blogs this month for the other parts of this series:

• Kevin Remde - Read Kevin's Full of I.T. blog
• Brian Lewis - Read Brian's My Thoughts on IT blog
• Matt Hester - Read Matt Hester's WebLog

What is Hyper-V Network Virtualization?

Any Service, Any Server, Any Data Center or Cloud!

True network and virtual machine portability - that's the ultimate goal of Hyper-V Network Virtualization - allowing you, as an IT Pro, to align changing business needs with the best physical resource locations to run your VMs and network services - easily, without the sweeping network, router, switch, firewall and DNS changes with which we'd traditionally be plagued when merely attempting the feat of relocating VMs to a new rack, subnet or data center ... WOW!

Windows Server 2012 and our FREE Hyper-V Server 2012 include a new network virtualization feature that permits the configuration of "software-defined networking (SDN)" within the native Hyper-V hypervisor.  Hyper-V Network Virtualization extends the virtualization benefits we've realized when virtualizing server workloads into the network layer to decouple our physical network infrastructure from logical layer-2 and layer-3 subnets as illustrated below:

Sounds Interesting! But, Why Use Hyper-V Network Virtualization Instead of Traditional VLANs?

Hyper-V Network Virtualization was intended to address the limitations and complexity seen in typical environments using VLANs, such as:

• Limited scalability - typical network switch configurations permit only 1,000 VLANs out of a maximum of 4,094 VLAN IDs.  In contrast, Hyper-V Network Virtualization can scale to support over 16 million virtualized networks.
   
• Configuration cost and complexity - environments using many VLANs need to carefully manage VLAN configurations on each switch, host and virtual machine to ensure a consistent experience.  In addition, enterprise VLAN configurations can require network switches with advanced processing capabilities from a single hardware vendor, often times making it difficult to cost effectively expand virtual network capacity.  Hyper-V Network Virtualization can be centrally implemented via network virtualization policies across a diverse network switch infrastructure and does not require special capabilities in the underlying network hardware.
   
• Constrained to a single subnet - Traditional VLANs are constrained to a single subnet, and although VLANs can be extended across physical sites, they must stretch one subnet at the network layer across those physical locations, which can cause extreme routing challenges - particularly when trying to leverage a combination of private data center resources along with hosted or public cloud resources.  Hyper-V Network Virtualization can present virtualized networks across diverse IP networks that extend across private, hosted and public cloud resources.

By removing these limitations, Hyper-V Network Virtualization extends the value of virtualization features that rely on network configurations.  As a I discuss these capabilities with IT Pros at our IT Camp events, three of the new scenarios that they are really excited about include:

1. Cross-subnet Live Migration of Virtual Machines - Live migrate running virtual machines to Hyper-V hosts on a different physical network subnet!  Hyper-V Network Virtualization extends virtualized subnets across one or more physical IP subnets, allowing Live Migration to be used across physical subnet boundaries. 
    
   Note: Cross-subnet Live Migration with Hyper-V Network Virtualization requires the use of Hyper-V over SMB 3.0 to provide shared VM storage to Hyper-V hosts on each physical subnet.  Hyper-V over SMB 3.0 uses cost effective file shares on Windows Server 2012 to provide a shared storage location that each Hyper-V can access for running and live migrating virtual machines.
    
2. IP Address and VM Portability across subnets and premises -  As business needs change, re-locate VMs to any datacenter, hosting provider or public cloud location WITHOUT changing the existing IP Addresses of the VMs! Today, numerous configuration choices are tied to the IP Address of each virtual machine - physical datacenter locations, firewall rules, router ACLs, directory services roles, etc - and this can make changing the IP Address of a deployed virtual machine a painful process.  As a result, many shops find that it's difficult to move VMs new host locations - such as new datacenter, hosted or public cloud locations - as business needs change, because these moves would generally require IP Address changes - not so with Hyper-V Network Virtualization!
    
3. Multi-tenancy with Overlapping IP Address ranges - This is a great solution for Hosting Providers, who need to ensure that each customer's collection of virtual machines are completely isolated at a network layer from other customers.  Each virtualized network can also use the customer's native IP addressing scheme, even if it would normally conflict with IP addressing schemes used by other customers.

How Does Hyper-V Network Virtualization Work?

Hyper-V Network Virtualization is implemented in Windows Server 2012 and Hyper-V Server 2012 as a new network driver module, Windows Network Virtualization (aka "ms_netwnv").  This module can be bound to physical NICs on each server and configured with a set of policies to virtualize network addressing and routing rules.  When configuring network virtualization, two different configuration approaches can be used:

• Generic Routing Encapsulation (NVGRE) - this approach builds GRE (RFC 2784 and 2890) tunnels between Hyper-V hosts to encapsulate virtualized networks using the details outlined  in the NVGRE Draft RFC document that has been submitted to the Internet Engineering Task Force (IETF).  This draft RFC document was assembled by a committee of networking veterans that includes senior engineers from Intel, DELL, HP, Emulex, Broadcom and Microsoft.  NVGRE is the preferred configuration approach for most network virtualization scenarios with Hyper-V hosts.
   
• IP Address Rewrite (IP Rewrite) - this approach uses a NAT-like approach at each Hyper-V host to rewrite virtualized network addresses to native network addresses that can be routed across the physical network architecture.  IP Rewrite is intended for scenarios where Virtual Machines require extremely high-performance network bandwidth, such as 10 Gbps Ethernet, since traditional NIC offload mechanisms are supported to increase throughput.

Since NVGRE is the preferred choice for most network virtualization scenarios, we'll be focusing on this approach for the reminder of this article.  However, check out this article if you're interested in more details on IP Rewrite and a deeper comparison between the two approaches.

What Changes Are Needed to My Existing Physical Network Switches?

NONE! NVGRE can be implemented across an existing physical IP network without requiring changes to your physical network switch architecture.  Since NVGRE tunnels terminate at each Hyper-V host, the hosts handle all of the handiwork for encapsulating and de-encapsulating network traffic.  If you have firewalls that are blocking GRE tunnels between sites, you will need to configure your firewalls to support forwarding GRE (IP Protocol 47) tunnel traffic.

Security Note: NVGRE tunnels do not natively provide encryption of payload contents.  If an NVGRE tunnel is being extended across public network segments, I recommend considering IPsec as part of your network layer policies to authenticate and encrypt network traffic end-to-end between virtual machine endpoints.

Performance Note: If you are planning to leverage NVGRE to virtualize heavy network IO workloads, you should also consider network adapter hardware that supports GRE Offload within the network chipset.  Without GRE Offload support within the NIC, traditional NIC offload technologies will not work with GRE traffic.  A number of NICs supporting GRE Offload for Windows Server 2012 and Hyper-V Server 2012 are expected later this calendar year.

I'm Ready! Where Do I Start?

The best starting place is to first layout the addressing scheme for IP addresses and subnets that you'd like to virtualize.  When configuring Hyper-V Network Virtualization, there are two types of IP Addresses that you'll be interacting with:

• Provider Addresses (PA) - these are unique IP addresses assigned to each Hyper-V host that are routable across the physical network infrastructure.  I like to think of "PA" addresses as "Physical Addresses", because they are assigned to physical Hyper-V hosts.  Each Hyper-V host requires at least one PA to be assigned.
   
• Customer Addresses (CA) - these are unique IP addresses assigned to each Virtual Machine that will be participating on a virtualized network.  I like to think of "CA" addresses as "Container Addresses", because they are the IP Addresses assigned to each VM "container" for use by the guest operating system running inside that VM.  Using NVGRE, multiple CA's for VMs running on a Hyper-V host can be tunneled using a single PA on that Hyper-V host.  CA's must be unique across all VMs on the same virtualized network, but CA's do not need to be unique across virtualized networks (such as in multi-tenant scenarios where each customer's VMs are isolated on separate virtualized networks).

Let's look at a simple example of NVGRE with two Hyper-V hosts using PA's and CA's:

In this example, you'll note that each Hyper-V host is assigned one PA address ( e.g., 192.168.x.x ) used for tunneling NVGRE traffic across two physical subnets ( e.g., 192.168.1.x/24 and 192.168.2.x/24 ) on the physical network.  In addition, each VM is assigned a CA address ( e.g., 10.x.x.x ) that is unique within each virtualized network and is tunneled inside the NVGRE tunnel between hosts. 

To separate the traffic between the two virtualized networks, the GRE headers on the tunneled packets include a GRE Key that provides a unique Virtual Subnet ID ( e.g., 5001 and 6001 ) for each virtualized network. 

Based on this configuration, we have two virtualized networks ( e.g., the "Red" network and the "Blue" network ) that are isolated from one another as separate IP networks and extended across two physical Hyper-V hosts located on two different physical subnets.

Once you have the following defined for your environment in a worksheet, you're ready to move on to the next steps in configuring Hyper-V Network Virtualization:

• PA's for each Hyper-V Host
• CA's for each Virtual Machine
• Virtual Subnet ID's for each subnet to be virtualized

Done! How Can I Configure Hyper-V Network Virtualization?

Hyper-V Network Virtualization policies can be centrally configured using PowerShell 3.0 and PowerShell Remoting for no additional cost.  In addition, System Center 2012 Virtual Machine Manager Service Pack 1, currently available as a public beta, also offers an enterprise GUI management console that can centrally deploy and manage Hyper-V Network Virtualization policies across a large number of Hyper-V hosts.

To understand the configuration steps for each type of virtual network addressing ( eg., PA's, CA's, Virtual Subnet IDs ) described above, let's step through the PowerShell 3.0 Cmdlets used to configure these policies one-by-one.  In these examples, we'll be focusing on the configuration steps for the "Blue" virtual network components on the Hyper-V hosts in the example illustrated above.  

Note: If you'll be using System Center 2012 to deploy and manage network virtualization policies as noted above, you won't need to manually run the specific PowerShell 3.0 Cmdlets below because System Center 2012 will run the appropriate PowerShell Cmdlets for you automatically to deploy the policies.  But, it still never hurts to understand what's happening behind the scenes! :-)

Here we go!  Let's get started configuring Hyper-V Network Virtualization via PowerShell 3.0 ...

1. Enable the Windows Network Virtualization binding on the physical NIC of each Hyper-V Host ( Host 1 and Host 2 )
    
   Enable-NetAdapterBinding Ethernet -ComponentID ms_netwnv
    
2. Configure Blue Subnet Locator and Route records on each Hyper-V Host ( Host 1 and Host 2 )
   
   New-NetVirtualizationLookupRecord -CustomerAddress "10.1.1.11" -ProviderAddress "192.168.1.10"   -VirtualSubnetID "6001" -MACAddress "101010101105" -Rule "TranslationMethodEncap" 

   New-NetVirtualizationLookupRecord -CustomerAddress "10.1.1.12" -ProviderAddress "192.168.2.20"   -VirtualSubnetID "6001" -MACAddress "101010101107" -Rule "TranslationMethodEncap" 

   New-NetVirtualizationCustomerRoute -RoutingDomainID "{11111111-2222-3333-4444-000000000000}" -VirtualSubnetID "6001" -DestinationPrefix "10.1.1.0/24" -NextHop "0.0.0.0" -Metric 255 
    
   Note: In the last command in this step above, a "RoutingDomainID" is also specified.  While this is not a network address per-se, each collection of virtualized networks that will route between each other must have a unique administrator-defined Routing Domain ID.  Using the example above, the "Blue" subnet and "Red" subnet do not have traffic routed between each other and, as such, would each require a unique Routing Domain ID.

3. Configure the Provider Address and Route records on Hyper-V Host 1 ( Host 1 Only )
    
   $NIC = Get-NetAdapter Ethernet

   New-NetVirtualizationProviderAddress -InterfaceIndex $NIC.InterfaceIndex -ProviderAddress "192.168.1.10" -PrefixLength 24 

   New-NetVirtualizationProviderRoute -InterfaceIndex $NIC.InterfaceIndex -DestinationPrefix "0.0.0.0/0" -NextHop "192.168.1.1"

4. Configure the Provider Address and Route records on Hyper-V Host 2 ( Host 2 Only )
    
   $NIC = Get-NetAdapter Ethernet

   New-NetVirtualizationProviderAddress -InterfaceIndex $NIC.InterfaceIndex -ProviderAddress "192.168.2.20" -PrefixLength 24 

   New-NetVirtualizationProviderRoute -InterfaceIndex $NIC.InterfaceIndex -DestinationPrefix "0.0.0.0/0" -NextHop "192.168.2.1"

5. Configure the Virtual Subnet ID on the Hyper-V Network Switch Ports for each "Blue" Virtual Machine on each Hyper-V Host ( Host 1 and Host 2 )
    
   Get-VMNetworkAdapter -VMName BlueVM1 | where {$_.MacAddress -eq "101010101105"} | Set-VMNetworkAdapter -VirtualSubnetID 6001
    
   Get-VMNetworkAdapter -VMName BlueVM2 | where {$_.MacAddress -eq "101010101107"} | Set-VMNetworkAdapter -VirtualSubnetID 6001 

That's it! Once you've gone through these 5 steps, you should now be able to route traffic between Virtual Machines across the "Blue" virtual subnet using the IP address space of 10.1.1.x / 24.

Note: If Windows Firewall is enabled on the operating system within each Virtual Machine, you may need to configure Windows Firewall within each VM to allow the traffic you're using to test.  For example, to permit ping traffic between VM's with Windows Firewall enabled, you can use the following PowerShell 3.0 Cmdlets in each VM:

New-NetFirewallRule –DisplayName “Allow ICMPv4-In” –Protocol ICMPv4

New-NetFirewallRule –DisplayName “Allow ICMPv4-Out” –Protocol ICMPv4 –Direction Outbound

What's Next? Keep Going!

Below are some great resources to continue your learning process on Hyper-V Network Virtualization ...

• Download: System Center 2012 Virtual Machine Manager Service Pack 1
• Watch: Hyper-V Network Virtualization for Scalable Multi-tenancy
• Do: Hyper-V Network Virtualization PowerShell Demo Script
• Read: Hyper-V Network Virtualization Gateway Architecture Guide
• Do: Hyper-V Network Virtualization with Gateway PowerShell Demo Script

How Are You Planning to Use Hyper-V Network Virtualization?

Have you found an interesting use case in your environment for Hyper-V Network Virtualization?  Be sure to share your story in the comments below!

HTH,

Keith