If you would like to read the other parts in this article series please go to:
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:
- New-NetVirtualizationProviderAddress -InterfaceIndex 17 -PrefixLength 24 -ProviderAddress “192.168.1.10”
- 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.
If you would like to read the other parts in this article series please go to:
