If you would like to read the other parts in this article series please go to:
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:
- 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.
- The WNV Module checks the destination CA IP address in the Lookup Table.
- If found, it again checks the MAC Address of the destination CA IP address and the VSID in the Lookup Table.
- It checks to make sure that the destination CA’s VSID matches with the source virtual machine’s VSID.
- If it does not match, the WNV will drop the packet stating that the VSID does not match.
- 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.
- 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.
- If the PA is a remote address, then the packet is modified and sent to the remote PA.
- 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.
If you would like to read the other parts in this article series please go to:
