Hyper-V and Networking – Part 2: VLANs

In the first part of this series, we started with the foundational concepts of networking in the OSI model and took a brief look at where Hyper-V components live in that model. In this part, we’ll build on that knowledge by looking at the operation of VLANs and how they work within the context of a Hyper-V deployment.


“VLAN” is an acronym for Virtual Local Area Network. This concept predates most of the virtualization technologies that are common today and should not be confused with anything in the computer virtualization or software-defined networking worlds.

To recap the first post, the VLAN exists at layer 2 in the OSI model. The significance is that this has nothing to do with IP addresses, although some of the basic rules are similar. Everything at this level is done by MAC address. Within any given Ethernet network, all endpoints must have a MAC address and all MAC addresses must be unique. Usually that’s not tough, given that any single prefix can have almost 17 million unique MAC addresses and manufacturers with that many devices also have more than one prefix.

What a VLAN does is set up a unique Ethernet network. The definition that I commonly see is that each VLAN represents a distinct “broadcast network”. While this explanation is the simplest, I dislike it as it is often confused with IP broadcasting. In Ethernet networking, a “broadcast network” indicates all the endpoints that will receive a frame transmitted to FF-FF-FF-FF-FF-FF. Even though it’s not a wonderful definition, most of the others get so complicated that you forget the question. So, rather than dig into it like that, just look at the functionality.

In a simple network using very basic switches, that means every single plugged-in and live endpoint will receive a broadcast. Switches capable of setting up VLANs can specify that some of their switch ports are members of a particular VLAN. So, an Ethernet frame traveling on VLAN 1 will not be delivered to any switchport that is not a member of VLAN 1. However, this distinction is entirely “virtual”. The only thing that sets the frames apart is the value in the 802.1q tag — and it might not even be there.

Many network devices can’t process an 802.1q tag at all. If an Ethernet frame is received with this tag, a great many devices will treat the frame as malformed. Most of the rest will ignore it. For this reason, you rarely want to point frames with 802.1q tags at physical devices other than switches. Usually, the tag is only present is when a frame passes through a “trunk”. A trunk is a single connection that carries multiple VLANs. In all other cases, switches keep track of which VLAN that traffic for a given port should be in.

Access Mode/PVID

In Cisco and Microsoft networking, ports can be set in “access mode”. If they aren’t set with anything else, then they will always communicate using untagged frames. In the Cisco world, this could be subjected to the device’s default VLAN. The Hyper-V switch has no default VLAN, or perhaps more properly, the default is always untagged. If the port is set to a specific VLAN, then that port becomes a member of that VLAN. Its frames are still untagged, but the switch will only allow that port to communicate with other devices on the same VLAN. The non-Microsoft/non-Cisco world corollary to an access mode port is PVID (port VLAN identifier). Only the term is different. Functionality is the same. To reiterate, access mode ports move traffic untagged, but only within a single specified VLAN.

Trunk Mode/Tagged

In Cisco and Microsoft networking, ports can be set in “trunk mode” instead of access mode. The purpose of trunk mode is to connect to another switch. In trunk mode, the port can become a member of multiple VLANs. VLANs that the trunk should process are added to the allowed list for Cisco and Microsoft switches. On most other devices, a port is considered to be in the equivalent of trunk mode by virtue of having one or more VLANs specified in its “tagged” list. Frames with other tags are discarded.

Native/Untagged VLANs

A trunk on a Cisco or Microsoft switch can be assigned a native VLAN. It then becomes a member of the network shared by all ports on the switch assigned to that VLAN just as it would if that were simply another of the allowed VLANs. Only one VLAN can be configured on a trunk in this method, or traffic in these VLANs would be inextricably combined into a single network. This is because frames that this trunk sends to the other switch travel without an 802.1q tag, and all incoming frames without a tag are treated as members of this VLAN. For a Cisco/Microsoft switch, this will be determined by the receiving trunk’s native VLAN setting. For all others, the equivalent fo the native VLAN is set by designating a single untagged VLAN for the trunk.

Comparing Cisco/Microsoft to other Manufacturers

The nice thing about the Cisco/Microsoft switches is that the usage of “access mode” and “trunk mode” make it pretty clear what’s going on. For everyone else, use “PVID” instead of “access mode” and “tagged” and/or “untagged” instead of “trunk mode”.

Hypothetical VLAN Configuration

Let’s look at an example. I have one Cisco 20-port smart switch (or a Microsoft Hyper-V external virtual switch) and one Netgear 20-port smart switch. I’m going to configure them as identically as possible, then plug them into each other.

In my network, I’ve decided that servers should participate in VLAN 10, desktops should participate in VLAN 20, and printers should participate in VLAN 30. On each switch, I want to designate ports 1-6 for servers, 7-12 for desktops, 13-18 for printers, and 20 for the link between switches. I will leave 19 unused.

Access Port Configurations

On the Cisco switch, I will set ports 1-6 in access mode for VLAN 10. I will set ports 7-12 in access mode for VLAN 20. I will set ports 13-18 in access mode for VLAN 30. I will plug in the devices as normal and just give them IP addresses as normal.

On the Netgear switch, I will assign ports 1-6 a PVID of 10. I will assign ports 7-12 a PVID of 20. I will assign ports 13-18 a PVID of 30.

Trunk Port Configurations

On the Cisco switch, I will set port 20 to trunk mode. I will give it a native VLAN of 10 and add 10, 20, and 30 to its allowed VLANs list.

On the Netgear switch, I will set port 20 so that it allows untagged traffic for VLAN 10 and tagged traffic for VLANs 20 and 30. As a matter of habit, I also usually set these with a PVID that matches the untagged VLAN, but I don’t think that’s actually necessary.


Now that this is done, I’ll plug in servers, desktops, and printers to all these ports as indicated. I will use a standard patch cable to connect port 20 on the Cisco switch to port 20 on the Netgear. Now, the server plugged into port 1 on the Cisco switch will be able to send and receive Ethernet frames directly to/from devices plugged into ports 2-6 and 20 on the Cisco switch and ports 1-6 and 20 on the Netgear switch. Those frames will never be tagged.

A desktop plugged into port 7 on the Cisco switch will be able to send and receive Ethernet frames directly to from devices in ports 8-12 on that switch and 7-12 on the other. However, unlike the VLAN 10 ports, its frames will cross the inter-switch link with an 802.1q tag of 20. Once these tagged frames arrive on the receiving switch, the tag is removed. But, the switch will only allow those frames to be visible to ports that are members of VLAN 10. This is the same behavior that will be seen for members of VLAN 20.

Port Channels/Link Aggregation

I know that at least a few of you are looking at that diagram and wondering why I wouldn’t put ports 19 and 20 on both switches into an aggregated link. The answer is: actually, I would. That’s not what this article is about though. We’ll revisit all that in a later installment.

Management VLANs

I haven’t talked about management VLANs, which is mostly because they’re not really in-scope for Hyper-V. Hyper-V either tags a frame or it doesn’t; it doesn’t really have a concept of a default VLAN or a management VLAN.

The management VLAN is really just a VLAN that compliant network devices will respond on. So, if I assign an IP of to a switch, it will give that IP address a presence inside its designated management VLAN’s Ethernet space. The default for most devices is VLAN 1, and for security purposes, it’s usually recommended that you change it. Since the Hyper-V switch has no IP address, it has no purpose for a management VLAN. The management VLANs are trunked and (un)tagged and accessed and PVID’d just like any other VLAN, although also for security purposes, it’s best if only network infrastructure devices’ management IPs are in it.

Hyper-V VLANs

The Hyper-V terminology usually lines up better with Cisco than with the others (confusing or not, these others are actually following standards most closely). The first difference is that you never really see anything about virtual switch ports unless you travel deep down the path where most are afraid to tread. Usually, you set these options directly on the virtual network adapter. That’s works well in this case because Hyper-V controls the switch, the switch ports, and the virtual network adapters. So, it doesn’t really need to distinguish between the port and the adapter.

When the Hyper-V virtual switch takes over a physical network adapter, that network adapter become an “uplink”. So, instead of the Cisco switch in our example network above, imagine that it’s a Hyper-V switch. The host’s physical adapter it’s assigned to is plugged into port 20 on the Netgear.
The big thing to be aware of is that we don’t, and can’t, configure this particular trunk “port” in Hyper-V. So, no native/untagged VLAN when connecting in to the physical network.

This just means that Hyper-V isn’t going to be able to strip VLAN ID’s from traffic leaving virtual machines. It will be able to accept incoming untagged traffic, of course. Just leave the VLAN ID off of any virtual adapter you want to receive from the incoming switch’s native VLAN ID. The Hyper-V switch’s “uplink” port will send the outgoing traffic of any VM without a defined VLAN without an 802.1q tag, so it will end up in the connected switch’s native VLAN.

Besides that, the Hyper-V virtual switch behaves like any other switch. Switch ports are set in access mode. As previously stated, any port without a defined VLAN winds up in the connected switch’s native or untagged VLAN. All other ports communicate on their designated VLAN, which is analogous to Cisco’s access mode or a non-Cisco switch’s PVID.

VLAN Isolation

By their very nature, VLANs are isolated. You can’t move traffic from one VLAN to another without communicating through a device that is present on both VLANs. There is a capacity issue, however, as there is a maximum of 4095 VLANs. There is a functionality issue if you need to connect duplicate IP subnets to the same router. While exceedingly rare in the SMB space, these situations are not uncommon at companies that host networks for others. As an example, you might have two clients who both use The easiest way to deal with that is to simply use a dedicated VLAN for each client and ensure that they can only communicate off of their own VLANs by using a router that employs network address translation (NAT). But, this is still subject to the scalability issue.

The first option is to use Private VLANs. This requires nothing other than what Hyper-V itself can provide. With this configuration, each virtual adapter to use a private VLAN has three configuration steps. First, it is set as promiscuous, community or isolated. Second, it is given a primary VLAN. Finally, depending on the mode, it is given a secondary VLAN or a list of allowed secondary VLANs. How it behaves depends on the first option that was set. This isn’t something I want to spend a lot of time on, first because I’m not very well-versed in it myself and second, I expect that if you really need it, you have access to a network engineer who can explain it to you and/or help you configure it.

The second option is to use network virtualization. This requires VMM, but it also allows you to create fully isolated networks. I also won’t spend much time on this, partially because I feel it’s been done better elsewhere, partially because I’m also not well-versed in it, and partially because, just like private VLANs, I don’t see where the majority of installations will have an immediate need for it. But, because I think that the hybrid cloud will eventually encroach on most of our networks. I do think this is something that’s worthwhile for most Hyper-V administrators to learn in the long run. Just not necessarily right away.

Hyper-V Switch Trunk Mode

The Hyper-V switch allows you to set a virtual adapter into trunk mode. The usefulness of this is in the eye of the beholder, since unlike a physical switch, a Hyper-V switch can only provide a connection between virtual machines and a single physical switch. So, aside from the trunk that exists on an external virtual switch represented by the physical NIC, it can’t trunk to any other switch. Also, as you’ll remember from the first post in this series, VLANs exist at layer 2. IP addresses don’t appear until layer 3.

The practical meaning of that is that all the things you’re used to configuring inside virtual machines know nothing about VLANs. The frames will arrive with the 802.1q tag intact, but you’ll need an application inside the guest that knows what to do with it in order to make any use of this feature. What I see people trying to do is set up the Windows Remote Access Service (RAS, formerly Routing and Remote Access Service, or RRAS) to process VLANs. RAS works at layer 3 and above, so it can’t process these VLAN tags.

Next Steps

As a natural segue, the next thing we’re going to do is step up from layer 2 to layer 3 and look at IP addressing and routing within the context of Hyper-V.

No comments:

Powered by Blogger.