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.
- Part 1 – Mapping the OSI Model
- Part 2 – VLANs
- Part 3 – IP Routing
- Part 4 – Link Aggregation and Teaming
- Part 5 – DNS
- Part 6 – Ports, Sockets, and Applications
- Part 7 – Bindings
- Part 8 – Load-Balancing Algorithms
Last updated: November 15, 2015.
“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 endpoint that is plugged-in and live 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.
Most network devices can’t process an 802.1q tag at all. If an Ethernet frame is received with one, they will treat the frame as malformed and 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.
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.
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.
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”.
Clarifying the Frames
Now that the terminology has been explained, we’ll return to the frames themselves. When it comes right down to it, there is only one functional difference between the operation of an access-mode port and a trunk-mode port, and that is the presence, or lack thereof, of the 802.1q tag. Packets that move across access ports should never have these tags. If they have them, the switch will get rid of them; to not to do would be a quick path to enabling a break-out attack. Packets that move across trunk ports will always have these tags.
Access frame (untagged) diagram:
Trunk frame (tagged) diagram:
It’s not entirely clear from the diagrams, because I didn’t want them to be too complex, but there’s only a single segment that gives any indication of how much data is in the packet. That’s in the portion that I marked as “length/type”. Notice where in the sequence that it sits. Since the preceding portions don’t have any indication of what’s coming, the device receiving the packet has to make assumptions. Therefore, a switch will assume everything coming in on a trunk port has an 802.1q tag and every packet coming in on an access mode port does not have an 802.1q tag. All other devices don’t even know that’s there’s any other type of frame than the one shown in the first image. So, if they receive a tagged frame, they believe that they’re parsing the length or type portion of the packet, but they’re actually looking at the 802.1q tag. To them, the packet looks malformed.
This is the reason that VLANs are numbered from 1-4096. You can, of course, have an all-zero tag, but there is no VLAN 0. The so-called “untagged” frame can’t cross a trunk port without the 802.1q tag being present. It just goes (or arrives) with all zeroes. But, as the above headings indicate, the “untagged” frame is not on access ports in the same way. The switch handles port membership. Packets always travel on those ports without even the space for an 802.1q tag.
As for the Hyper-V switch, this is one reason why it doesn’t have a “default VLAN”. It doesn’t really need one. If you don’t designate a VLAN for any given virtual network adapter, then it will be in the “default VLAN”. Packets coming in to the Hyper-V switch with an empty tag can be delivered to those adapters. Packets coming out of them meant for the external world will be sent out with an empty 802.1q tag and the receiving switch will place them into whatever VLAN it has set as untagged or native for its trunk. I suspect another reason that the Hyper-V virtual switch doesn’t use a numbered default VLAN might be related to the fact that it also needs to be able to connect to switches that can’t handle 802.1q tags. When configuring a hardware smart switch to talk to such a simple switch, you’d just leave its port in access mode. Hyper-V’s uplink doesn’t grant the distinction.
Hypothetical VLAN Configuration
Let’s look at an example deployment that uses all of these concepts. 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.
So that there’s no confusion on default VLAN vs. untagged/native VLAN, most standard smart switches only allow VLAN 1 to be the default VLAN for access mode ports. There is no coupling between a trunk port’s untagged/native VLAN and any of the access ports. In case this isn’t clear, remember that a single switch can have multiple trunk ports with their own untagged/native VLANs. This behavior is different from the Hyper-V virtual switch, which simply does not number its “default” VLAN.
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 still only allow those frames to be visible to ports that are members of VLAN 20 (ports 7-12). So, while a packet moves between ports on the same switch, the switch knows which port members to expose it to by port VLAN membership. When a packet is sent between switches, the sending switch will place an 802.1q tag it so that the receiving switch knows which of its ports it can be exposed to. Once the receiving switch knows what that packet’s tag is, it will remove the tag.
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.
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 192.168.75.100 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.
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.
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 192.168.0.0/24. 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.
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.