Deep Dive into Hyper-V Network Virtualization
Nirmal Sharma
POSTED ON JUNE 19, 2014
________________________________________
Contents
Deep Dive into Hyper-V Network Virtualization (Part 1) 1
Introduction 2
Terms Used Throughout The Article 3
Hyper-V Network Virtualization Overview 4
Why do you need Hyper-V Network Virtualization? 5
Summary 6
Deep Dive into Hyper-V Network Virtualization (Part 2) 7
Summary 12
Deep Dive into Hyper-V Network Virtualization (Part 3) 13
Summary 17
Deep Dive into Hyper-V Network Virtualization (Part 4) 18
VSID 18
Summary 22
Deep Dive into Hyper-V Network Virtualization (Part 5) 23
Lookup Table 23
Lookup Table Mechanism 26
Conclusion 27
Introduction
Software Defined Networking, sometimes referred to as SDN, is very popular amongst cloud hosting providers nowadays. Software-defined networking (SDN) is an approach to computer networking in which hardware networking control is decoupled and given to a software application. Microsoft has designed a similar software application called “Windows Network Virtualization” (WNV) which enables in virtualizing the Layer 2 and Layer 3 networking models.
Microsoft Hyper-V has been a great success and many customers from SMBs to large organization have implemented Hyper-V to virtualize their physical environment. Initially, Hyper-V was released with some basic functionality to enable organizations to virtualize their physical environment. In its current version, included with Windows Server 2012 R2, Hyper-V is robust as VMware and has almost all the features offered by VMware. 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.
I have seen many sysadmins/consultants and cloud architects looking for more information on Hyper-V Network Virtualization topic. Since the technology is new and adoption of HNV is very less, it is hard to find every aspect of the HNV in a single document or a site. That’s where this article series comes handy. This article series provides enough details on Hyper-V Network Virtualization technology and how components provided by WNV work together to implement the Hyper-V Network Virtualization.
The first part of this article series clearly focuses on the overview and benefits of Hyper-V Network Virtualization. We are going to touch upon the following topics in first part of this article series:
• Terms used throughout the article
• Hyper-V Network Virtualization Overview
• Why do you need Hyper-V Network Virtualization
Terms Used Throughout The Article
Before tackling Hyper-V Network Virtualization, there are a few basic terms that I ought to define in case you aren’t familiar with them.
WNV Module A module named “Windows Network Virtualization” available in Windows Server 2012 and later versions which helps in implementing Hyper-V Network Virtualization technology.
HNV HNV stands for Hyper-V Network Virtualization.
IP Rewrite IP Rewrite is a software mechanism in which virtual packets are re-written to native physical addresses.
NVGRE NVGRE stands for Network Virtualization Generic Routing Encapsulation. NVGRE uses mechanism to perform encapsulation and de-capsulation on incoming and outoing packets.
VSID Virtual Subnet ID (VSID) is a component of WNV Module and is assigned to virtual machines participating in Hyper-V Network Virtualization.
Table 1
Hyper-V Network Virtualization Overview
Windows Network Virtualization or WNV, a networking module which was introduced with Windows Server 2012, provides the necessary components to implement Hyper-V Network Virtualization technology. WNV is an extensible module. The functions implemented by WNV Module can be used by the third party vendors to develop software applications for Hyper-V Network Virtualization. The virtual machine events cause the WNV module to generate the event notifications which can be received by the third-party software which, in turn, can take a pre-defined action. WNV fits very well with the Microsoft’s Extensible Virtual Switch architecture.
Since this article series is geared primarily towards Hyper-V Network Virtualization and its components, explaining every bit of WNV and Hyper-V Extensible Virtual Switch will not be possible. However, you can take a look at this link if you want to read more about WNV module and Hyper-V Extensible Virtual Switch.
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. Since WNV Module works with the Hyper-V Role, you must make sure to enable Hyper-V Role on a computer running Windows Server 2012 or Windows Server 2012 R2.
Using WNV Module, two different Hyper-V Network Virtualization configuration approaches can be used; “NVGRE” or “IP Rewrite”.
• NVGRE: NVGRE (Network Virtualization Generic Routing Encapsulation) uses GRE 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.
• IP Rewrite: In case of IP Rewrite mechanism, the CA IP Address is re-written to native physical network address. The IP Rewriting mechanism is not used much because of requirement of one PA Address for each CA virtual machine. Since the IP Rewrite requires a large pool of PA Addresses, the common implementation of Hyper-V Network Virtualization can be seen using NVGRE protocol which is the focus of this article series.
Why do you need Hyper-V Network Virtualization?
• Bring Your Own IP Address: Every organization would like to move their enterprise services to a shared IaaS cloud without any need for changing the IP Address scheme and the network topologies. Microsoft Hyper-V Network Virtualization makes this possible. Customers can bring their own IP Addresses and network topologies while making sure there’s not much time spent in network planning before the move takes place.
• More virtual networks without using VLANs: Secondly, cloud hosting providers greatly benefit by eliminating the need for using VLAN tagging system. We use VLAN Tagging system for isolation purposes. VLAN tagging presents complexity when it comes to host multiple customers on a shared IaaS cloud. Not only does using VLAN Tagging present complexity, but also you need to ensure that network devices are configured to allow the VLAN traffic.
Using HNV, there is no need to use the VLAN Tagging system for isolation purpose. Cloud hosting providers now can use VSID, which is a component of WNV Module, to provide the isolation between customer virtual machines.
• Cross-subnet Live Migration of Virtualized Workloads: It becomes easier for cloud hosting providers to move virtualized workloads from datacenter to datacenter without any downtime. Previously, live migration was limited to the same subnet restricting where virtual machines could be located. Hosting providers can use Live Migration technology to live migrate virtual machines across different virtual subnets without a service disruption. Cross subnet live migration allows administrators to consolidate virtualized workloads based on dynamic resource requirements and can also accommodate infrastructure maintenance without disrupting customer workload up time.
• VSID: There is a limitation associated with the physical switches for VLAN IDs. Physical switches allow 1000 VLANs to be used out of 4096 IDs. Hyper-V Network virtualization does not use VLANs. Instead, HNV uses VSID (Virtual Subnet ID) to separate virtual machine communications. The VSID range starts from 4096 to 16,777,214. Using VSIDs, 16 million virtual subnets can be hosted as opposed to the limitation imposed by the VLAN which is only 4096 VLANs.
• Easy way to implement: HNV can be implemented either using SCVMM (System Center Virtual Machine Manager) or HNV PowerShell cmdlets. Using PowerShell cmdlets, virtual administrators can build automated scripts to configure HNV policies. HNV PowerShell cmdlets can be found here. SCVMM is a datacenter management product which is designed to ease the deployment of HNV.
• No Need to modify Existing Network Device Configuration: HNV technology is compatible with today’s datacenter network and can be implemented successfully without requiring any changes to the network devices.
Summary
In the first part of this article series, we learned about the Hyper-V Network Virtualization and benefits it provides to cloud hosting providers. In the next part and so, we will learn about the Hyper-V Network Virtualization components and see how these components play an important role to implement Hyper-V Network Virtualization
Deep Dive into Hyper-V Network Virtualization (Part 2)
We’re not going to demonstrate NVGRE configuration, but will explain the various components involved in Hyper-V Network Virtualization with the help of HNV design shown below and also learn about the PowerShell cmdlets we need to use to configure Hyper-V Network Virtualization. To limit the discussion, we will focus on how these components fit together to implement the Hyper-V Network Virtualization. Before I start explaining the WNV components, let me give you an overview of HNV design explaining how these components look like in a network virtualization design when configured for multiple customers on a shared IaaS cloud.
Hyper-V Network Virtualization, sometimes referred to as HNV Networking, involves various components. The technology is built of CA, PA, VSID, RDID/VM Network and Lookup Table components. These are the core components of WNV Module as shown in the below HNV design:
Figure 1.1: Hyper-V Network Virtualization and its components
As shown in the figure 1.1 above, there are two Hyper-V Hosts running; Host1 and Host2. Both Hyper-V Hosts are running multiple virtual machines from different customers. A few virtual machines are running with the same IP scheme on both the Hyper-V Hosts. Blue Virtual Machines belong to Customer-A and Red Virtual Machines belong to the Customer-B.
As shown above, customer virtual machines are running on three virtual subnets; two virtual subnets (10.1.1.0 and 10.1.2.0) for Blue Virtual Machines and 1 virtual subnet (10.1.1.0) for Red Virtual Machines.
Blue1 and Red1 virtual machines are running on the Hyper-V Host1 with the same IP Address (10.1.1.11). Blue2 and Red2 virtual machines are also running with the same IP Address (10.1.1.12) but on Hyper-V Host2. These virtual machines are configured on the same virtual subnet, but are using different VSIDs (6001 and 6002). The VSID is what makes it possible to run virtual machines with the same IP Address. You don’t encounter any IP conflict issue for Blue1 and Red1 virtual machines because they are configured with different VSIDs. If you remove VSIDs or assign the same VSIDs, you will be encountered with the IP conflict issue.
Tip:
VSID is similar to VLAN ID. The only difference is that VLAN ID cannot be used with Hyper-V Network Virtualization, instead you must use VSID.
Blue3 and Blue4 Virtual Machines belong to Customer-A. These virtual machines are running on a separate virtual subnet (10.1.2.0) and VSID configured for these virtual machines is 6005.
You also see something called “PA Address” which is assigned to each Hyper-V Host (PA 192.168.1.10 for Hyper-V Host1 and 192.168.2.20 for Hyper-V Host2). PA is responsible for managing virtual machines running on the local Hyper-V server and takes necessary actions to reach out virtual machines running on remote Hyper-V servers. PAs talk to each other to manage communication between customer virtual machines. I will talk more about PA in the next part of this article series.
A virtual machine participating in the Hyper-V Network Virtualizations is called CA (Customer Address). All Blue and Red virtual machines are CA as shown in the above design.
Since there are two customer virtual machines running on both the Hyper-V Hosts, isolation is necessary. To provide isolation between virtual machines of different customers, we have created two RDIDs; one for Blue virtual machines and another one for Red virtual machines. RDID is known as Routing Domain ID which is a requirement for Hyper-V Network Virtualization.
So basically, the design has the following components of WNV Module implemented:
• Two customers – Customer A (Blue virtual machines) and Customer B (Red Virtual Machines)
• Two RDIDs – One for each customer.
• Three Virtual Subnets using different VSIDs – 10.1.1.0: 6001, 10.1.1.0: 6002 and 10.2.1.0: 6005
• Two PA Addresses – 192.168.1.10 and 192.168.2.20
• Six CA Virtual Machines – Blue1, Blue2, Blue3, Blue4, Red1 and Red2
And the overall goal of the HNV design shown above is to make sure:
• Customers can bring their own IP Address and network topologies.
• There is no need to make any changes to the physical network topology.
• Virtual Machines with the same IP scheme can run on Hyper-V Hosts.
• Customer-A virtual machines can talk to each other.
• Customer-B Virtual Machines can talk to each other.
• None of the Blue and Red virtual machines should be able to communicate with each other as they belong to different customers.
• Virtual machines can be live migrated across different subnets.
Hyper-V Network Virtualization makes it possible to accomplish the above goal. Now, let’s take a closer look at all the WNV Components. In this part of this article series, we will only focus on “RDID” component.
RDID: RDID, sometimes referred as Routing Domain ID, is a routing domain boundary in which virtual machines can communicate with each other but cannot talk to virtual machines running in another RDID. In the above design, there are two RDIDs; one RDID is for Blue virtual machines and another RDID is created for Red Virtual Machines. Virtual Machines Blue1, Blue2, Blue3 and Blue4 belong to RDID 1 and Red1 and Red2 virtual machines belong to RDID 2. RDID provides isolation between customer virtual machines and is a requirement for implementing Hyper-V Network Virtualization. RDID is a 128 bit long Windows GUID. Each customer must have its own RDID.
As you can see, Blue1 and Red1 virtual machines are running with the same IP Scheme. This is because they are implemented in different RDID with different VSID. An RDID must be created with a unique VSID to ensure there is no IP conflict. You will see an IP conflict issue if you do not assign VSID to Red1 and Blue1 virtual machines or if both the virtual machines are using the same VSID. So just creating the RDID alone would not suffice. You must also assign a unique VSID to virtual machines.
You need to use New-NetVirtualizationCustomerRoute PowerShell cmdlet to create an RDID for a customer. Before you create the RDID for a customer, please make sure the following statements are true:
• No other customer hosted on the same shared IaaS Cloud is using the same RDID GUID.
• RDID GUID must be either generated using SCVMM or PowerShell cmdlet. You can also create a GUID manually but it must be a valid Windows 128 bit GUID.
• You must also obtain a Virtual Subnet ID (VSID) which is not being used by any other customer on the network.
An example of an RDID created using PowerShell cmdlet is listed below:
1. New-NetVirtualizationCustomerRoute -DestinationPrefix “10.1.1.0/24” -NextHop “0.0.0.0” -RoutingDomainID “{11111111-2222-3333-4444-000000006002}” -VirtualSubnetID 6002
2. New-NetVirtualizationCustomerRoute -DestinationPrefix “10.1.2.0/24” -NextHop “0.0.0.0” -RoutingDomainID “{11111111-2222-3333-4444-000000006001}” -VirtualSubnetID 6001
3. New-NetVirtualizationCustomerRoute -DestinationPrefix “10.1.2.0/24” -NextHop “0.0.0.0” -RoutingDomainID “{11111111-2222-3333-4444-000000006005}” -VirtualSubnetID 6005
Since you have two customer Virtual Machines running on both the Hyper-V Hosts, you must create two RDIDs for isolation purposes. New-NetVirtualizationCustomerRoutePowerShell cmdlet must be executed for each virtual subnet in an RDID.
The 1st command creates an RDID for Red Virtual Machines (Customer-A). 2nd and 3rd commands are executed to create another RDID for Blue Virtual Machines (Customer-B). As you notice, there are two commands executed for Blue Virtual Machines. This is because there are two virtual subnets with two VSIDs for Blue Virtual Machines. Since the command can accept only one VSID at a time, you must ensure to execute New-NetVirtualizationCustomerRoute PowerShell command for each virtual subnet and VSID using the same RDID GUID.
Tip:
To generate a new RDID GUID, you can use the below PowerShell cmdlet command:
• $NewGUID = [guid]::NewGuid()
Note:
New-NetVirtualizationCustomerRoute command must be executed on both the Hyper-V Hosts. In other words, all Hyper-V Hosts must be aware of all customer RDIDs.
To get the list of RDIDs created on Hyper-V Hosts, you can use the Get-NetVirtualizationCustomerRoutePowerShell cmdlet as shown in the figure 1.1 below:
• Get-NetVirtualizationCustomerRoute | ft RoutingDomainID, VirtualSubnetID, DestinationPrefix, NextHop -auto
Figure 1.2: Getting RDID configuration on Hyper-V Host
As you notice in the figure 1.2, the command displays the list of RDIDs configured on local Hyper-V Host. You must ensure that the same configuration is returned when you execute the command on other Hyper-V Hosts where customer virtual machines are running.
Summary
In the 2nd part of this article series, we saw how an HNV design looks. We also explained the RDID component of HNV and the PowerShell commands a virtual administrator needs to execute to create RDID for each customer on each Hyper-V Host.
In the next part, we will continue to focus on HNV Components including VM Network, PA, CA, VSID, Virtual Subnets, and Lookup Table and see how these components play an important role in implementing Hyper-V Network Virtualization
Deep Dive into Hyper-V Network Virtualization (Part 3)
The second part of this article series explained the RDID component of the WNV module. In the third part of this article series, we continue to explore the other components of the WNV module, including the VM Network, PA, CA and Virtual Subnet. For the purposes of this article series, we have used an HNV design in Part II. It is necessary that I also include the same HNV design in this part so that it is easy for you to refer the HNV components, which I am going to explain shortly.
Figure 1
VM Network: This is the logical network boundary created for virtual machines participating in the Hyper-V Network Virtualization. As shown in the above HNV design, the Blue1, Blue2, Blue3 and Blue4 virtual machines belong to a VM Network. Similarly, Red1 and Red2 virtual machines belong to another VM Network. A VM Network consists of multiple virtual subnets. For example, in the above HNV design, there are two virtual subnets created for Customer-A (10.1.1.0 and 10.1.2.0) in a VM network, and one virtual subnet is created for Customer-B (10.1.1.0) in another VM Network.
Each VM Network has a Routing Domain ID, which identifies the VM Network. The Routing Domain ID (RDID) is assigned by using either the SCVMM or PowerShell cmdlets. Please refer to Part II of this article series to learn more about RDID.
Provider Address (PA): PA is responsible for handling the virtual machine traffic across Hyper-V hosts. It is assigned to the physical network adapter of the external virtual switch.The PA is an IP address, which holds the responsibility to look for inbound and outbound traffic for customer virtual machines and then allow virtual machines to communicate at the physical layer. As shown in the above HNV design, the PA 192.168.1.10, which is assigned to the Hyper-V Host1, can only be responsible for handling NVGRE traffic for Blue1, Red1, and Blue4 virtual machines. The PA 192.168.2.20, which is assigned to the Hyper-V Host2, can only manage Blue3, Blue2 and Red2 virtual machines running on the Hyper-V Host2.
It is important to understand that the PA can only manage virtual machines, which are participating in the Hyper-V Network Virtualization. As shown in the above HNV design, there is a “Non-HNV-VM” virtual machine running on the Hyper-V Host2, which is not participating in the Hyper-V Network Virtualization. Hence, this virtual machine will not be managed by the PA.
Can PA manage all virtual machines running on a Hyper-V host? It completely depends on the Hyper-V Network Virtualization deployment model you choose. You can have either one PA managing all virtual machines, or one PA managing only one virtual machine. There are three HNV deployment models provided by the Hyper-V Network Virtualization. Explaining each deployment model in detail is out of the scope of this article, but I will provide an overview of each HNV deployment model. Three HNV deployment models are:
• One PA for all virtual machines using NVGRE
• One PA per Virtual Subnet using NVGRE
• One PA per virtual machine using IP ReWrite
In case of “One PA for all virtual machines using NVGRE” deployment model, all customer virtual machines are managed by one PA address. This PA address is responsible for managing all CA virtual machines running on a Hyper-V server. This is the HNV deployment model that we are using in this article series. This HNV deployment model uses NVGRE protocol to perform encapsulation and de-capsulation on incoming and outgoing virtual packets.
If you choose “One PA per virtual subnet using NVGRE” model, it provides you with the flexibility in terms of managing PA and virtual machine policy entries on the Hyper-V hosts.
The third HNV deployment model is to use “One PA per virtual machine using IP ReWrite”. This deployment model uses the IP ReWrite mechanism, which requires one PA per virtual machine. In this deployment model, the PA can only manage one virtual machine. This deployment model is not used often due to the requirement of one PA per virtual machine.
Note:
IP ReWrite is no longer used in Windows Server 2012 R2.
Remember that before the PA can manage virtual machines participating in the Hyper-V Network Virtualization, the PA must be assigned to each Hyper-V host. There are two ways to assign PAs to Hyper-V hosts; using either SCVMM or HNV PowerShell cmdlet. To assign PA using PowerShell cmdlets, use New-NetVirtualizationProviderAddresscmdlet, as listed in the below commands:
1. New-NetVirtualizationProviderAddress -InterfaceIndex 17 -PrefixLength 24 -ProviderAddress “192.168.1.10”
2. New-NetVirtualizationProviderAddress -InterfaceIndex 17 -PrefixLength 24 -ProviderAddress “192.168.1.20”
The first command is executed on the Hyper-V Host1, and the second command is executed on Hyper-V Host2. “InterfaceIndex 17” is the physical network adapter to which the External virtual switch is mapped to.
You can get “InterfaceIndex” by executing the Get-NetAdapter PowerShell cmdlet, as shown in the below screenshot:
Figure 2
To make sure you have successfully assigned the PA on both the Hyper-V Hosts, execute the Get-NetVirtualizationProviderAddress on both the Hyper-V hosts, as shown in the below screenshot:
• Get-NetVirtualizationProviderAddress | FTProviderAddress,InterfaceIndex,PrefixLength–auto
Figure 3
The above command is executed on the Hyper-V Host1 to list the PA, which is assigned to InterfaceIndex 17. Execute the same command on the Hyper-V Host2 to make sure you see the same result for PA 192.168.2.20, but the “InterfaceIndex” could be different.
Just assigning the PA addresses will not work. You must also create policy entries. A static mapping entry must be created for each PA and virtual machine participating in the Hyper-V Network Virtualization. I’ll talk more about the static mapping later in this article series. Before we talk about PA + CA policy entries, let’s learn about the CA component of the WNV module.
Customer Address (CA): A virtual machine, participating in the Hyper-V Network Virtualization, is known as the CA. The CA is the IP address assigned to the virtual machine. As shown in the above HNV design, 10.1.1.11 and 10.1.1.12 are the CA IP addresses, which are assigned to the Blue1 and Blue2 virtual machines, for example. The Blue1, Blue2, Blue3, Blue4, Red1 and Red2 are known as the CA virtual machines. The CA IP and its MAC Address are used to create the policy entry in the Lookup Table on the Hyper-V host. I’ll explain the Lookup Table in the final part of this article series.
Virtual Subnet: Virtual machines, in the same virtual subnet, must use the same IP subnet prefix. Similarly, all virtual machines in a virtual subnet must use the same VSID so that they belong to the same virtual subnet. As shown in the above HNV design, there are three virtual subnets (10.1.1.0, 10.1.1.0 and 10.1.2.0). Blue1 and Blue2 virtual machines belong to the virtual subnet 10.1.1.0, and a VSID 6001 is assigned to these virtual machines. Similarly, Red virtual machines belong to the virtual subnet 10.1.1.0, and a VSID 6002 is assigned to these virtual machines. Blue3 and Blue4 virtual machines belong to the virtual subnet 10.1.2.0, but the VSID assigned to these virtual machines is 6005.
What you see in above HNV design is that the virtual machines, running in a virtual subnet, use the “same” VSID. You can have multiple virtual subnets created, but the virtual machines running in these virtual subnets must not overlap. For example, you cannot assign the VSID 6001 to the Red1 and Red2 virtual machines because this VSID is already in use by the Blue virtual machines. If you do so, you might encounter IP conflict issues and it is actually not supported.
Summary
In this part, you learned about the VM Network, PA, CA and Virtual Subnet components of the WNV module. The VM Network is a logical boundary, and it is automatically created when you create the RDID. As you learned, the PA is responsible for managing virtual machines on a Hyper-V host, but the PA manages the virtual machines, depending on the HNV deployment model you choose.
In the next part, we will learn about the VSID, as well as how using VSID will help isolate customer virtual machines
Deep Dive into Hyper-V Network Virtualization (Part 4)
VSID
VSID, sometimes referred to as the Virtual Subnet ID, is assigned to customer virtual machines. This is different from the VLAN ID, which is assigned from the property page of a virtual machine. A virtual machine participating in Hyper-V Network Virtualization must be assigned with a VSID, not a VLAN ID. You cannot assign the VLAN ID to a virtual machine if it is already configured with a VSID, and vice-versa. Traditional VLAN ID range starts from 1 to 4095, whereas the VSID range is from 4096 to 16,777,214. Hyper-V Network Virtualization separates the customer virtual machines using the VSIDs assigned to them. The VSID assignment can be done automatically by using either the SCVMM, or manually using the HNV PowerShell cmdlets. If you need to assign the VSID to a virtual machine using PowerShell, use the Set-VMNetworkAdapter cmdlet.
The Set-VMNetworkAdapter is not a new PowerShell cmdlet designed to support Hyper-V Network Virtualization implementation, but it does support “VirtualSubnetID” parameter which helps you assign VSID´s to virtual machines. To assign VSID using Set-VMNetworkAdapter, execute the below commands on both the Hyper-V hosts:
On Hyper-V Host1
1. Get-VMNetworkAdapter -VMName Blue1 | where {$_.MacAddress -eq “00155D013202”} | Set-VMNetworkAdapter -VirtualSubnetID 6001
2. Get-VMNetworkAdapter -VMName Blue4 | where {$_.MacAddress -eq “00155D013203”} | Set-VMNetworkAdapter -VirtualSubnetID 6002
3. Get-VMNetworkAdapter -VMName Red1 | where {$_.MacAddress -eq “00155D013204”} | Set-VMNetworkAdapter -VirtualSubnetID 6005
On Hyper-V Host2
1. Get-VMNetworkAdapter -VMName Blue2 | where {$_.MacAddress -eq “00155D013205”} | Set-VMNetworkAdapter -VirtualSubnetID 6001
2. Get-VMNetworkAdapter -VMName Blue3 | where {$_.MacAddress -eq “00155D013206”} | Set-VMNetworkAdapter -VirtualSubnetID 6001
3. Get-VMNetworkAdapter -VMName Red2 | where {$_.MacAddress -eq “00155D013207”} | Set-VMNetworkAdapter -VirtualSubnetID 6001
The first, second and third commands are executed on the Hyper-V Host1 because Blue1, Blue4 and Red1 virtual machines are running on the Hyper-V Host1. Please refer to the HNV design that we are using for the purposes of this article series in Part 1. The fourth, fifth, and sixth commands are executed on the Hyper-V Host2 because Blue2, Blue3 and Red2 virtual machines reside on the Hyper-V Host2.
The above commands make sure that these virtual machines are isolated completely. They are never allowed to talk to a virtual machine, which is in a different VM Network/RDID. It is important to note that even though the Blue1 and Blue4 virtual machines are using different VSID, they are still part of the same RDID/VM Network. Since these virtual machines are part of the same RDID/VM Network, they can communicate with each other without requiring any further configuration. Blue1 and Blue4 virtual machines cannot communicate with the Red1 and Red2 virtual machines because the Red1 and Red2 virtual machines belong to a different RDID/VM Network. Hence, RDID/VM Network and VSID assignment play an important role in isolating the customer virtual machines on a shared IaaS cloud.
Note that the VSID is assigned to the “virtual network adapter” of a virtual machine. A virtual machine can have multiple virtual network adapters connected to it. You must assign the VSID to the correct virtual network adapter of the virtual machine. In the previous commands, we have used the Get-VMNetworkAdatper PowerShell cmdlet to filter the virtual machine by the MAC Address and then assign the VSID to the correct virtual network adapter. There is no need to use the Get-VMNetworkAdapter PowerShell cmdlet if all the virtual machines have only one virtual network adapter configured. In that case, you can simply run the Set-VMNetworkAdapter command with the –VirtualSubnetID parameter to assign the VSID.
If you try to assign VLAN ID to a virtual machine for which a VSID ID is already assigned, you will get an error message as shown in the below screenshot:
Figure 1
Similarly, if a virtual machine is already configured with a VLAN ID and if you try to configure the VSID, you will get an error message as shown in the below screenshot:
Figure 2
The error does not specifically say that the VLAN ID is already assigned to the virtual machine. Instead, the error message indicates that the operation has failed while applying the switch port settings. It is therefore important to make sure that the virtual machines, participating in Hyper-V Network Virtualization, are not already assigned with a VLAN ID.
Note:
Virtual machine will not participate in Hyper-V Network Virtualization if the VSID´s are not assigned to them. In other words, a virtual machine assigned with a VSID 0 will be ignored by the WNV module.
To make sure that virtual machines have been assigned with a VSID, you can use the Get-VMNetworkAdapterPowerShell cmdlet, as shown in the below screenshot:
• Get-VMNetworkAdapter * | FT VMName, MACAddress, VirtualSubnetID –Auto
Figure 3
As you can see in the above screenshot, virtual machines (Red1, Blue4 and Blue1) are assigned with a unique VSID. Execute the same command on the Hyper-V Host2 to make sure that the result matches with the HNV design.
The VSID information, populated in the Lookup Table for virtual machines, must match with the VSID assigned to the virtual machines. In case VSID does not match, the packet will be dropped by the WNV Module. I will talk more about the logic used by the WNV module to look for the destination virtual machine in the final part of this article series.
At this stage,
• You have configured the isolation for the virtual machines by using multiple WNV components.
• You used the RDID, VM Network and VSID to isolate the customer virtual machines.
• You can configure the virtual machine to use the IP addresses. For example, you can configure Red1 and Red2 virtual machines to use the same IP Address, and they will not conflict.
Summary
In this part, we learned how the VSID plays an important role in isolating the customer environment from other customers, as well as how the VLAN ID is different from the VSID. In the next part of this article series, we will learn about the Lookup Table. Without the Lookup Table, it wouldn’t be possible for the WNV Module to locate the virtual machines running on local/remote Hyper-V Hosts. In the next post of this article series, we are going to closely look at the Lookup Table, as well as the logic used by the WNV module to look for the destination virtual machines running either on local or remote Hyper-V hosts.
I would recommend reading other parts of this article series to make sure you are aware of the WNV module components, which have been explained throughout this article series
Deep Dive into Hyper-V Network Virtualization (Part 5)
In the previous parts of this article series, we spoke about the different components of the WNV module. These components play an important role when implementing the Hyper-V Network Virtualization. Before you plan to read the final part of this article series, I would recommend reading other parts to make sure you are aware of the other components of the WNV module, which have been explained throughout the previous parts.
Lookup Table
The Lookup Table is used by the WNV module to look for the destination CA IP address on the local or remote Hyper-V hosts. Without the Lookup Table, it will not be possible for the WNV module to reach out to the virtual machines that are running on either the local or remote Hyper-V hosts. In other words, the Hyper-V host must have knowledge of all the virtual machines that are participating in the Hyper-V Network Virtualization.The WNV module on the Hyper-V host will always search the destination CA IP Address in its Lookup Table before the virtual packet’s destination can be known. For example, if Blue1 and Blue2 virtual machines need to communicate with each other, the Lookup Table must have the necessary policy entries for these virtual machines.
The policy entries in the lookup table can be automatically populated by using either the SCVMM or manually using PowerShell cmdlet. To manually populate policy entries using PowerShell, you can use the New-NetVirtualizationLookupRecord PowerShell cmdlet. For example, the below policy entries are populated in the Lookup Table on both the Hyper-V hosts for all virtual machines participating in the Hyper-V Network Virtualization. This is to ensure that the VM traffic is handled by the WNV module:
• New-NetVirtualizationLookupRecord -VMName Blue1 -CustomerAddress “10.1.1.11” -ProviderAddress “192.168.1.10” -VirtualSubnetID “6001” -MACAddress “00155D013202” -Rule “TranslationMethodEncap”
• New-NetVirtualizationLookupRecord -VMName Blue4 -CustomerAddress “10.1.2.22” -ProviderAddress “192.168.1.10” -VirtualSubnetID “6005” -MACAddress “00155D013403” -Rule “TranslationMethodEncap”
• New-NetVirtualizationLookupRecord -VMName Red1 -CustomerAddress “10.1.1.11” -ProviderAddress “192.168.1.10” -VirtualSubnetID “6002” -MACAddress “00155D013204” -Rule “TranslationMethodEncap”
• New-NetVirtualizationLookupRecord -VMName Blue2 -CustomerAddress “10.1.1.12” -ProviderAddress “192.168.1.20” -VirtualSubnetID “6001” -MACAddress “00155D013205” -Rule “TranslationMethodEncap”
• New-NetVirtualizationLookupRecord -VMName Blue3 -CustomerAddress “10.1.2.20” -ProviderAddress “192.168.1.20” -VirtualSubnetID “6005” -MACAddress “00155D013406” -Rule “TranslationMethodEncap”
• New-NetVirtualizationLookupRecord -VMName Red2 -CustomerAddress “10.1.1.12” -ProviderAddress “192.168.1.20” -VirtualSubnetID “6002” -MACAddress “00155D013207” -Rule “TranslationMethodEncap”
As per the HNV design shown in Part 1 of this article series, you have six virtual machines running on both the Hyper-V hosts. For each virtual machine, you must create a policy entry in the Lookup Table. The CA IP, CA MAC Address, PA and VSID are the minimum information required before you can create a policy entry in the Lookup Table. When you create a policy entry, you also provide a PA address. This PA + CA mapping ensures that the WNV module always forwards the traffic for the CA VM to the PA address configured in the policy entry.
Basically, a policy entry in the Lookup Table looks like below:
New-NetVirtualizationLookupRecord -VMName <Name of VM> -CustomerAddress<This is the IP Address of the VM> -ProviderAddress <This PA will be responsible for managing this VM>-VirtualSubnetID <This is the VSID of the VM> -MACAddress <MAC Address of the VM> -Rule <I want the traffic to be handled either using NVGRE or IP ReWrite mechanism>
You might have noticed the use of –Rule parameter in the above commands. “TransaltionMethodEncap” value in the –Rule parameter suggests the command that it must use NVGRE, or the encapsulation/de-capsulation method to modify the CA packet. If you need to use the IP ReWrite method, you must use the “TranslationMethodNAT” value in place of the “TranslationMethodEncap”.
Tip:
It is not required to install virtual machines before you build the Lookup Table. The Lookup Table can also be built beforehand.
To make sure the policy entries have been successfully populated for all the virtual machines participating in the Hyper-V Network Virtualization, execute the Get-NetVirtualizationLookupRecord PowerShell cmdlet on both the Hyper-V hosts (Hyper-V Host1 and Hyper-V Host2), as shown below:
• Get-NetVirtualizationLookupRecord | FT VMName,CustomerAddress,MACAddress,VirtualSubnetID,ProviderAddress -auto
Figure 1
As shown in the above screenshot, which is taken on the Hyper-V Host1, all virtual machines have the policy entries populated in the Lookup Table. Each virtual machine is associated with a VSID and a PA. These virtual machines are being managed by two PA Addresses (PA 192.168.1.20 and 192.168.1.10). These PA addresses receive the packet from the WNV Module, and then take the necessary actions. The same set of policy entries must also exist on the Hyper-V Host2.
Lookup Table Mechanism
It is the WNV module which receives the notification about incoming or outgoing virtual machine packets. The WNV module uses the below logic to check if the Destination CA IP belongs to a local or remote Hyper-V host:
1. The WNV module receives the packet from source CA (virtual machine). The packet has the information about source IP, source MAC Address, source VSID, and destination IP address.
2. The WNV Module checks the destination CA IP address in the Lookup Table.
3. If found, it again checks the MAC Address of the destination CA IP address and the VSID in the Lookup Table.
o It checks to make sure that the destination CA’s VSID matches with the source virtual machine’s VSID.
o If it does not match, the WNV will drop the packet stating that the VSID does not match.
o If the source and destination VM’s VSID matches, then check the PA which is responsible to handle the traffic for destination CA IP address.
o If the PA is a local address, then the packet is sent to the local PA.The PA receives the packet and sends to all ports of the virtual switch.
o If the PA is a remote address, then the packet is modified and sent to the remote PA.
4. If the destination CA IP is not found in the Lookup Table, the WNV drops the packet locally.
You see the importance of the policy entries in the Lookup Table. HNV cannot work without the Lookup Table. The WNV module will filter the packet if the following conditions are true for the Destination CA IP Address:
• There is no policy entry for the destination CA IP address in the Lookup Table.
• The VSID of destination CA IP does not match with the VSID of source CA IP.
Conclusion
You saw how Hyper-V Network virtualization helps in achieving the isolation for customer virtual machines that are running on a shared IaaS cloud. Hyper-V Network Virtualization reduces the complexity seen in today’s network by providing you with the VSID design, which can be used to host more than 16 million virtualized networks, as well as to help secure the environment in such a way that the customer virtual machines are not allowed to access any other customer virtual machines.
The RDID, PA, CA, VM Network, Virtual Subnet, VSID, and Lookup Table components of the WNV module have been designed to accomplish the Software Defined Networking in Microsoft Hyper-V. These components, when implemented together, work with each other to implement Hyper-V Network Virtualization