Deep Dive into Hyper-V Network Virtualization (Part 2)

If you would like to read the other parts in this article series please go to:

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:

Image
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-NetVirtualizationCustomerRoute PowerShell 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-NetVirtualizationCustomerRoute PowerShell cmdlet as shown in the figure 1.1 below:

  • Get-NetVirtualizationCustomerRoute | ft RoutingDomainID, VirtualSubnetID, DestinationPrefix, NextHop -auto

Image
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.

If you would like to read the other parts in this article series please go to:

1 thought on “Deep Dive into Hyper-V Network Virtualization (Part 2)”

  1. I think there is an error in this command:

    New-NetVirtualizationCustomerRoute -DestinationPrefix “10.1.2.0/24” -NextHop “0.0.0.0” -RoutingDomainID “{11111111-2222-3333-4444-000000006001}” -VirtualSubnetID 6001

    The -DestinationPrefix “10.1.2.0/24” should be “10.1.1.0/24”

    Please confirm

Leave a Comment

Your email address will not be published.

Scroll to Top