Which Hyper-V network virtualization deployment Model you should choose?

Understanding the differences between Hyper-V network virtualization deployment models will help you choose the approach that will work best for you.

Software defined networking is getting a lot of attention lately and Microsoft has designed a software application called Windows Network Virtualization (WNV) which enables virtualizing the Layer 2 and Layer 3 networking models. Beginning with Windows Server 2012, Microsoft’s primary focus has been to develop Hyper-V further for cloud hosting providers and enable customers to move services more easily to a shared IaaS cloud.

Windows Network Virtualization is a networking module introduced with Windows Server 2012, that provides the components necessary to implement network virtualization. You are required to enable the WNV module on Windows Server 2012 by executing a PowerShell command, but starting with Windows Server 2012 R2, WNV is integrated into the Hyper-V virtual switch.

There are two important components of WNV module which play an important role in enabling the Hyper-V Network Virtualization; Provider Address (PA) which is owned by the hosting providers and Customer Address (CA) which is the IP address assigned to a customer virtual machine on a shared IaaS cloud. The PA manages the CA packets to be routed between the Hyper-V virtual switches. A combination of  PA and CA addresses are used to create the policy entries in the routing table. The routing table is interpreted by the WNV module to reach CA virtual machines either on local or remote Hyper-V servers.

There are two different Hyper-V Network Virtualization configuration approaches available using the MNV module: Network Virtualization Generic Routing Encapsulation  (NVGRE) and IP Rewrite. These configuration approaches provide three different Hyper-V Network Virtualization deployment models. The deployment model you choose will depend on your requirement. Choosing the deployment model affects your PA option which is explained in this article.

NVGRE uses a generic routing encapsulation mechanism to perform encapsulation and de-capsulation on incoming and outgoing packets. Microsoft is the dominant vendor for introducing NVGRE protocol. Other companies supporting the development of NVGRE include Arista Networks, Mellanox, Broadcom, Dell, Emulex, Intel and Hewlett-Packard. NVGRE configuration approach supports two types of HNV deployment models: One PA for all CA virtual machines and One PA per CA Virtual Subnet.

In case of One PA for all CA Virtual Machines, HNV deployment model, all customer CA virtual machines are assigned to only one PA address. This PA address is responsible for managing all CA virtual machines running on a Hyper-V Server and take necessary actions to route the packets to the virtual switches on local or remote Hyper-V Servers as shown in the below figure.

One PA for all CA virtual machines

As you can see in above figure, one PA address (192.168.10.2) is managing all CA virtual machines for all customers hosted on a shared IaaS cloud. This HNV deployment model is suitable for small hosting providers that host few virtual machines for customers and do not have enough PA addresses available. An example of implementing this type of deployment model using New-NetVirtualizationLookupRecord PowerShell cmdlet requires that you create necessary policy entries in the routing table as listed below:

  • New-NetVirtualizationLookupRecord -VMName VM1 -CustomerAddress "10.0.0.2" -ProviderAddress "192.168.10.2" -VirtualSubnetID "6001" -MACAddress "00155D013202" -Rule "TranslationMethodEncap"
  • New-NetVirtualizationLookupRecord -VMName VM2 -CustomerAddress "10.0.0.3" -ProviderAddress "192.168.10.2" -VirtualSubnetID "6001" -MACAddress "00155D013202" -Rule "TranslationMethodEncap"
  • New-NetVirtualizationLookupRecord -VMName VM3 -CustomerAddress "10.0.0.4" -ProviderAddress "192.168.10.2" -VirtualSubnetID "6001" -MACAddress "00155D013202" -Rule "TranslationMethodEncap"
  • New-NetVirtualizationLookupRecord -VMName VM4 -CustomerAddress "10.0.0.5" -ProviderAddress "192.168.10.2" -VirtualSubnetID "6001" -MACAddress "00155D013202" -Rule "TranslationMethodEncap"

As you notice in the above commands, for all four CA virtual machines, only one PA address is associated. There are other PowerShell commands you execute to configure HNV but explaining those are out of scope of this article.

In case of One PA per Virtual Subnet, the PA manages CA virtual machines per virtual subnet as shown in the below figure.

One PA for each virtual subnet

As shown in above figure, PA address 192.168.10.2 is managing all CA virtual machines which belong to virtual subnet 10.0.0.0 and PA address 192.168.20.2 is responsible for managing all CA virtual machines which are associated with 10.0.20.0 virtual subnet. This HNV deployment model is more flexible in terms of managing the PA and CA policy entries in the routing table. This deployment model is also sometimes referred as One PA for Each Customer.

Both One PA for all CA Virtual Machines and One PA per Virtual Subnet deployment models can only be configured using the NVGRE networking configuration approach.

In case of IP Rewrite mechanism, the CA IP Address is re-written to native physical network addresses. As the name suggests, Hyper-V virtual switch rewrites the source IP address and destination IP address to the corresponding provider address before the packet leaves the virtual network. IP rewriting mechanism supports only one HNV deployment model which is One PA per CA Virtual Machine. For each CA virtual machine, you must assign one PA address. The disadvantage with One PA Per CA Virtual Machine networking model is that it requires one PA for each CA as shown in the below figure:

One PA address for each CA virtual machine

As you see in the above figure, there are four CA virtual  machines running on a Hyper-V Server. Each CA virtual machine is managed by its own PA address. When implementing Hyper-V Network Virtualization, you will be using a CA and PA combination to create the policy entries in the Routing Table as listed in below commands:

  • New-NetVirtualizationLookupRecord -VMName VM1 -CustomerAddress "10.0.0.2" -ProviderAddress "192.168.10.2" -VirtualSubnetID "6001" -MACAddress "00155D013202" -Rule "TranslationMethodNAT"
  • New-NetVirtualizationLookupRecord -VMName VM2 -CustomerAddress "10.0.0.3" -ProviderAddress "192.168.10.3" -VirtualSubnetID "6001" -MACAddress "00155D013203" -Rule "TranslationMethodNAT"
  • New-NetVirtualizationLookupRecord -VMName VM3 -CustomerAddress "10.0.0.4" -ProviderAddress "192.168.10.4" -VirtualSubnetID "6001" -MACAddress "00155D013204" -Rule "TranslationMethodNAT"
  • New-NetVirtualizationLookupRecord -VMName VM4 -CustomerAddress "10.0.0.5" -ProviderAddress "192.168.10.5" -VirtualSubnetID "6001" -MACAddress "00155D013205" -Rule "TranslationMethodNT"

As you notice in the above commands, when creating policy entries in the routing table using New-NetVirtualizationLookupRecord PowerShell cmdlet, the CA IP address is mapped to the corresponding PA address. TranslationMethodNAT value, specified using the -Rule switch indicates that the WNV module must use IP Rewrite mechanism when modifying the packets. WNV module uses these policy entries to find out the corresponding Provider Address which is responsible for managing a CA virtual machine.

There are a few advantages associated with IP rewrite mechanisms as stated below:

  • IP rewrite mechanism is appropriate to provide performance since it adds very little overhead to the network process.
  • The packet format is not changed. Hence, IP rewrite is fully compatible with existing network equipment.
  • Existing network hardware offload technologies such as Large Send Offload (LSO) and Virtual Machine Queue (VMQ) can function as expected.

The IP rewrite configuration approach, which provides only one networking deployment model, is not much used because of the requirement of one PA Address for each CA virtual machine. Since this networking deployment model requires a large pool of PA Addresses, the common implementation of Hyper-V Network Virtualization can be seen using the NVGRE configuration approach and deployment models as explained in this article.

This was first published in April 2014

Dig deeper on Network virtualization

Pro+

Features

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

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:

-ADS BY GOOGLE

SearchVMware

SearchWindowsServer

SearchCloudComputing

SearchVirtualDesktop

SearchDataCenter

Close