Hyper-V virtual networks and VLANs

There are three types of virtual networks that we can create in a Hyper-V host: private, internal and external.

Each virtual network is implemented by a virtual switch. There is an one-to–one correspondence between virtual networks and virtual switches and the terms “virtual network” and “virtual switch” are used interchangeably. Each virtual network is unaware of the other virtual networks and is disconnected from them.

A private virtual network allows communications between virtual machines in the same Hyper-V host. An internal virtual network allows  communications between virtual machines in the same host and the host’s parent partition. An external virtual network allows communications between virtual machines in the same host, the host’s parent partition and the external network through one of the host’s physical network adapters.

When a private virtual network is created, the following happens:
• A new virtual switch is created.

When an internal virtual network is created, the following things happen:
• A new virtual switch is created.
• A new virtual network adapter for the parent partition is created.
• The new virtual network adapter for the parent partition is connected to the new virtual switch.

When an external virtual network is created, the following things happen:
• A new virtual switch is created.
• A new virtual network adapter for the parent partition is created.
• The new virtual network adapter for the parent partition is connected to the new virtual switch.
• A physical network adapter of our choice is connected to the new virtual switch.

It is important to mention that each physical NIC can be connected to only one external virtual switch and vice versa. In other words, there is a one-to–one correspondence between external virtual networks and physical NICs. If we want to create a new external virtual network, we cannot assign to it a physical NIC already assigned to another external virtual network; instead, we must specify another available and unassigned physical NIC. For a more thorough explanation of the previous concepts read Virtuatopia’s “Understanding and Configuring Hyper-V Virtual Networks”.

It is also important to mention that when an external virtual network is created, all settings of the associated physical NIC are turned off and the only protocol that is bound to it is the Microsoft Virtual Network Switch Protocol. The virtual NICs (of the parent partition and of the virtual machines) that connect to the external virtual switch will be the ones with all the settings (protocols, services, IP address, VLAN ID etc.). If you want to find out about more of what is happening behind the scenes when a virtual network is created, refer to the following:
• “Understanding Networking with Hyper-V” from the Virtual PC Guy’s WebLog.
• The last paragraph of Microsoft’s “Hyper-V Getting Started Guide”.
• “How does basic networking work in Hyper-V?” from John Howard’s blog.
• “Configuring virtual networks in Hyper-V” by Nelson Ruest and Danielle Ruest, which is a video tutorial.

Dell Networking Solutions Guide for Microsoft Hyper-V” and John Howard’s “Hyper-V: What are the uses for different types of virtual networks?” contain excellent depictions of the three types of virtual networks (along with a fourth, the equivalent of an external virtual network with the virtual network adapter for the parent partition disabled: a useful configuration where the parent partition is not connected to the virtual switch, but the virtual machines that are connected to the virtual switch are allowed external access).

When we are about to create a new virtual network, the dialog box in Figure 1 is shown.

Figure 1: Dialog box for creating a new virtual network

Figure 1: Dialog box for creating a new virtual network

Figure 1: Dialog box for creating a new virtual network.

Again, for any new virtual network (either private, internal or external), a new virtual switch will be created.

If an internal or external virtual network is chosen, then a new virtual network adapter for the parent partition will be created and it will be connected to the new virtual switch.

Of course, all the communications of the new virtual network adapter for the parent partition will be through the new virtual switch.

If  we choose to create an external virtual network, a physical network adapter will also be connected to the new virtual switch. This adapter is chosen from the drop-down list in Figure 1.

The setting “Enable virtual LAN identification for parent partition” is for the new virtual network adapter for the parent partition. It is not for the new virtual switch.
If we choose it, then the new virtual network adapter for the parent partition will tag all its communications with this VLAN ID. This setting appears only if the virtual network type is internal or external. This setting is dimmed in the case of the private virtual network type, since in that case no virtual network adapter is created for the parent partition.

So the dialog box in Figure 1 that appears in order to aid us in the configuration of the new virtual network contains configuration elements for both the new virtual network switch (name, notes, virtual network type, physical adapter to connect to the new virtual network switch in case the type is external) and for the new virtual network adapter that will be created for the parent partition (the optional VLAN ID in case the type is internal or external).

When we want to connect a virtual machine’s virtual network adapter to a virtual network, we use the dialog box in Figure 2.

Figure 2: Dialog box for connecting a VM’s virtual NIC to a virtual network

Figure 2: Dialog box for connecting a VM’s virtual NIC to a virtual network

Figure 2: Dialog box for connecting a VM’s virtual NIC to a virtual network.

When we highlight a VM’s virtual network adapter, its properties appear in the dialog box shown in Figure 2. From the drop down list we select the virtual network that the adapter will be connected to.

If we want to tag the virtual adapter’s communications with a VLAN ID, we can check the “Enable virtual LAN identification” check box and enter the VLAN ID.

This is exactly what we do when we create a new internal or external virtual network: we provide the VLAN ID for the virtual network adapter that will be created in the parent partition and that will be connected to the new virtual network.

Here, we provide the VLAN ID for the virtual machine’s virtual network adapter that will be connected to the virtual network we specify.

In Figures 1 and 2, the check boxes “Enable virtual LAN identification for parent partition” and “Enable virtual LAN identification” are used for the same thing, which is to assign a VLAN ID to a virtual network adapter. The check box of the dialog box in Figure 1 assigns the VLAN ID to the virtual adapter that will be created for the parent partition as a step of the creation of the new virtual switch. The check box of the dialog box in Figure 2 assigns the VLAN ID to the virtual machine’s virtual adapter that we choose to connect to the virtual switch.

The adapters that connect to the same virtual network switch do not have to have the same VLAN ID. But if the parent partition’s or a virtual machine’s virtual adapter uses a VLAN ID and another virtual machine’s virtual adapter uses another VLAN ID, then these two will not be able to communicate, even if they connect to the same virtual network switch.

A parent partition’s virtual network adapter is created at the same time the virtual network is created in the dialog box in Figure 1 and it is there that a VLAN ID is associated with this adapter. A virtual machine’s virtual network adapter is connected to a virtual network and given a VLAN ID in the dialog box in Figure 2, in the properties of the virtual network adapter.

We can have the following situation with two Hyper-V hosts:

Host A hosts its parent partition, Virtual Machine 1, Virtual Machine 2 and Virtual Machine 3. It has an external virtual network to which a physical adapter, the parent partition and the three VMs are connected.
• The parent partition’s virtual NIC uses VLAN ID 10 (set in Figure 1).
• VM 1’s virtual NIC uses VLAN ID 20 (set in Figure 2).
• VM 2’s virtual NIC uses VLAN ID 30 (set in Figure 2).
• VM 3’s virtual NIC uses no VLAN ID.
Because of the difference in VLAN IDs, the parent partition and the three VMs cannot communicate with each other.

Host B hosts its parent partition, Virtual Machine 4, Virtual Machine 5 and Virtual Machine 6. It has an external virtual network to which a physical adapter, the parent partition and the three VMs are connected.
• The parent partition’s virtual NIC uses VLAN ID 20 (set in Figure 1).
• VM 4’s virtual NIC uses VLAN ID 30 (set in Figure 2).
• VM 5’s virtual NIC uses VLAN ID 10 (set in Figure 2).
• VM 6’s virtual NIC uses no VLAN ID.
Because of the difference in VLAN IDs, the parent partition and the three VMs cannot communicate with each other.

Then if we connect the physical adapters of the two hosts with a physical switch, we will have the following:
• Host A’s parent partition will be able to communicate with VM 5.
• VM 1 will be able to communicate with host B’s parent partition.
• VM 2 will be able to communicate with VM 4.
• VM 3 will be able to communicate with VM 6.

The physical switch and the physical network adapters of the two hosts need to support the IEEE 802.1Q VLAN tagging standard for the previous configuration to work. The configuration is shown in Figure 3.

Figure 3: Two Hyper-V hosts are connected to the same physical switch

Figure 3: Two Hyper-V hosts are connected to the same physical switch

Figure 3: Two Hyper-V hosts are connected to the same physical switch.

The concepts behind this configuration are discussed in Robert Larson’s “Virtual LAN (VLAN) support in Hyper-V“, Adam Fazio’s “Understanding Hyper-V VLANs” and Microsoft Consulting Services’ “Provisioning Hyper-V Virtual Machine in Hosting Environment“.

So why would someone use VLAN tagging? In other words, why would someone need to separate traffic by creating VLANs? There are two sets of reasons, performance and security ones. Performance wise, whereas switches help avoid collisions, switches with VLANs also confine broadcasts. But you know all about collision domains and broadcast domains. And security is obvious since VLANs confine network traffic. For any two VLANs to communicate, we need a router.

Sometimes, the security reasons behind the setting of VLANs can be of a technical nature. For example, there are times when we want to isolate traffic from specific DHCP or WDS servers to specific client machines. No production machines should be able to “see” a DHCP or WDS server that was only meant to be used for test purposes.

And what about the “moral” of the story? Why did I write this post? I wrote it for two main reasons. First, I wanted to make clear that the dialog box in Figure 1, which is the properties dialog box of a virtual switch, configures not only the virtual switch, but also the parent partition’s virtual NIC that connects to the virtual switch (in the cases of external and internal virtual networks, where this virtual NIC exists).  Second, I wanted to make clear that the VLAN ID in Figure 1 and the VLAN ID in Figure 2 are both VLAN IDs that we assign to virtual network adapters, the first to a virtual NIC of the parent partition, the second to a virtual NIC of a virtual machine.

In my attempt to emphasize these two points, I had to left out several things.

*** First of all, looking at Figure 3, I’ve tried to draw everything nicely and neatly. (I don’t know about my choice of colours, though). But in reality, in the Hyper-V hosts, the physical NIC is also connected to the parent partition. That makes the parent partition multi-homed. It’s OK, as long as we know about it. “Dell Networking Solutions Guide for Microsoft Hyper-V” explains what we need to be careful of. And it is in this context that the fourth type of virtual network (which Dell and John Howard propose as I mentioned in the beginning) can be of use.

*** What we do here is dynamic VLAN tagging. Static VLAN tagging is when we define a VLAN in each port in the switch and not in the individual virtual NICs. We cannot have static VLAN tagging in Figure 3, because he have only one physical NIC connected to one port of the physical switch and through it traffic must pass from all VLANs. Dynamic VLAN tagging is our only option here. Read Robert Larson’s “Virtual LAN (VLAN) support in Hyper-V” for an excellent explanation of the two types of tagging and for VLANs in Hyper-V.

*** I’ve said nothing about IP addresses, although IP address configuration is the most important thing! Each VLAN should be on its own subnet and VMs 3 and 6 should be on their own subnet as well. Now what about the physical NICs? The only thing bound to the physical NICs is the Microsoft Virtual Network Switch Protocol. This happened during the creation of the external virtual networks, as I explained in the beginning of this post. So no IP address assignment for the physical NICs.

*** Whereas in Figure 3 we look at a single physical switch, in its place is probably our whole networking infrastructure. We need to be able to set it up to provide the two hosts with connectivity.

In the case of a single switch, we first have to define the VLANs. Then we have to setup the two ports of the switch that connect it to the two hosts. Each of the two ports should be in trunk mode and in dot1q encapsulation.

Trunk mode means that each port should not belong to a single VLAN, but should accept traffic for all VLANs. Dot1q encapsulation means that the network packets will carry the VLAN ID in the way the IEEE 802.1Q (here is the dot1q) VLAN tagging standard describes. What encapsulation means in this case is that each packet will have an entry in its OSI Layer 2 header that will have the VLAN ID, the tag. In other words, the VLAN ID is placed inside the packet’s Layer 2 header. So, the standard does not perform a real encapsulation of the whole network packet, despite the name given to this procedure.

If instead of a switch we have a whole series of switches, each switch in the path must have the VLANs defined and have the necessary ports setup in trunk mode. Instead of manually defining the VLANs in each and every switch, there are automatic ways to do it and protocols that help, but (let me clear my throat and change to my formal voice) “this is beyond the scope of this post”.

*** When I thought about the configuration in Figure 3, I wanted it exactly as it is, although I was afraid that it might steer a controversy. I am talking about VMs 3 and 6, which use no VLAN IDs. There is a school of thought that considers this a bad practice. In simple terms, they suggest that we either tag nothing or tag everything. I agree with them. Well, I don’t agree, if the case is about a very large network where almost every machine, port and packet is untagged and only two machines need to be in a VLAN; there you should not start tagging all other communications. But in a configuration like the one in Figure 3, it makes sense to tag everything.

But this configuration is not about best practices. It is about what can be done, what is possible in Hyper-V.

Another reason the untagged VMs 3 and 6 might raise eyebrows, is that there is an incorrect belief that tagged and untagged traffic cannot flow together through a VLAN trunk (the connection from the physical NIC to the physical switch that lets all VLANs pass through). Let me make this clear: the IEEE 802.1Q standard allows it.  I cannot comment on your particular physical NICs and physical switches though, so if you find problems, try tagging all VMs and see if the problems go away. This way you can pinpoint the source of the trouble. There is something called the native VLAN, and what this really is, it is the VLAN that the untagged traffic is associated with. The native VLAN should be the same on both ends of a trunk connection.

There are two types of trunks, depending on how they treat the untagged packets. The first type tags them at the ingress and untags them at the egress using the native VLAN ID. The second type lets every packet through without tagging and untagging them.  But the end effect is the same for both types of trunks: tagged and untagged packets pass through. It is up to the the particular manufacturer as to how they implement their end of the trunk, so its best to have switches that are all from the same vendor.

*** Now, don’t go on about defining VLANs in the physical NICs of the two hosts. This is not only unnecessary, but will also destroy the dynamic nature of the setup.

Let me explain. Many physical NICs have utilities that let us define VLANs. Each VLAN that we define this way looks (to the system) like a separate “physical” NIC attached to the host. If we go that road, then we would have as many “physical” adapters as VLANs. And we will have to create as many external virtual networks as there are VLANs. Each VLAN will have its own external virtual network.

Imagine the following (exaggerated) situation: We have 50,000 virtual machines. Each virtual machine belongs to a VLAN. All and all there are 100 VLANs. Each VLAN has 500 virtual machines (100*500=50,000). Now these virtual machines are hosted in 5,000 Hyper-V hosts. Each host hosts 10 virtual machines on average (again, 5,000*10=50,000). We are allowed to transfer virtual machines from a host to another whenever we wish.

Now, with a setup like the one in Figure 3, only the virtual NIC of each virtual machine and the physical switch need to be setup with VLAN IDs. And only one external virtual network need to exist in each host.

But if we go the other direction, and define VLANs in each host’s physical NIC, then we will end up with 5,000 hosts that each will have 100 new “physical” adapters (the utilities create the equivalent of a physical adapter for each VLAN) each connected to a different external virtual network. So, each host will have 100 new “physical“ NICs and 100 external virtual networks. And all this just to service the 10 (on average) virtual machines that happen to be hosted there at the time. I do not like this configuration.

If we follow the example in Figure 3, then in the configuration of each host we will look at one physical NIC and one external virtual network. I like this configuration.

There are benefits to the configuration where we define the VLANs in the physical NIC (a different external virtual network for each VLAN is neat), but I do not think that its scales well and I do not find it flexible enough. It is great for small or medium sized networks though.

So, if we are to implement the configuration in Figure 3, the only place we should define VLAN IDs is in the physical switches and in the virtual NICs. So leave the physical NICs alone. Well, we might have to enable them to support the IEEE 802.1Q standard, if they are not enabled by default. How to do that depends on the particular NIC. Sometimes a setting in its properties, other times a registry entry, other times we find and install new drivers. But it is always best to follow the advice of the server’s vendor, if the NIC came with server.

*** In Figure 3, I give an example where each host has only one physical NIC, to prove my points. But don’t buy servers with only one NIC! You need several physical NICs in each host: one NIC for management, two for iSCSI connectivity to your SAN (if you have an iSCSI SAN, you need connectivity that is fast and highly available), one for intra cluster communications (if you are going to setup a cluster) and of course one or more for the virtual machines’ external communications (the real purpose the host exists in the first place). For more information read “Provisioning Hyper-V Virtual Machine in Hosting Environment” from Microsoft Consulting Services.

And that’s it. After this I am feeling a little hyper. Don’t get me wrong; Hyper-V is great, but I don’t know about drinking it (Figure 4). Maybe I should stick to regular soda!

Figure 4: Hyper-V: A promising hypervisor, an exciting technology, a smooth(?) drink

Figure 4: Hyper-V: A promising hypervisor, an exciting technology, a smooth(?) drink

Figure 4: Hyper-V: A promising hypervisor, an exciting technology, a smooth(?) drink.

References

Understanding and Configuring Hyper-V Virtual Networks
Virtuatopia
http://www.virtuatopia.com/index.php/Understanding_and_Configuring_Hyper-V_Virtual_Networks

Understanding Networking with Hyper-V
Virtual PC Guy’s WebLog
http://blogs.msdn.com/virtual_pc_guy/archive/2008/01/08/understanding-networking-with-hyper-v.aspx

Hyper-V Getting Started Guide
Microsoft
http://technet.microsoft.com/en-us/library/cc732470.aspx

How does basic networking work in Hyper-V?
John Howard
http://blogs.technet.com/jhoward/archive/2008/06/16/how-does-basic-networking-work-in-hyper-v.aspx

Configuring virtual networks in Hyper-V
Nelson Ruest and Danielle Ruest
http://searchwindowsserver.techtarget.com/video/0,297151,sid68_gci1342743,00.html

Dell Networking Solutions Guide for Microsoft Hyper-V
Dell
https://support.dell.com/support/edocs/software/HyperV/en/nsg/nsga00.pdf

Hyper-V: What are the uses for different types of virtual networks?
John Howard
http://blogs.technet.com/jhoward/archive/2008/06/17/hyper-v-what-are-the-uses-for-different-types-of-virtual-networks.aspx

Virtual LAN (VLAN) support in Hyper-V
Robert Larson
http://www.virtualizationadmin.com/articles-tutorials/microsoft-hyper-v-articles/networking/introduction-vlan.html

Understanding Hyper-V VLANs
Adam Fazio
http://blogs.msdn.com/adamfazio/archive/2008/11/14/understanding-hyper-v-vlans.aspx

Provisioning Hyper-V Virtual Machine in Hosting Environment
Microsoft Consulting Services
http://download.microsoft.com/download/A/2/F/A2F199C0-672E-44E6-BF1D-878E233C3F08/ProvisioningHyper-VVirtualMachineinHostingEnvironment.docx

Advertisements

About Dimitrios Kalemis

I am a systems engineer specializing in Microsoft products and technologies. I am also an author. Please visit my blog to see the blog posts I have written, the books I have written and the applications I have created. I definitely recommend my blog posts under the category "Management", all my books and all my applications. I believe that you will find them interesting and useful. I am in the process of writing more blog posts and books, so please visit my blog from time to time to see what I come up with next. I am also active on other sites; links to those you can find in the "About me" page of my blog.
This entry was posted in Administration. Bookmark the permalink.