Save to My DOJO
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.
VLANs
“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.
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”.
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:
Access Mode Packet
Trunk frame (tagged) diagram:
Tagged Packet
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.
Results
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.
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 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.
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 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.
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.
Not a DOJO Member yet?
Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!
More in this category
About the Author
Eric Siron
82 thoughts on "How to Set up VLANs in Hyper-V"
The foundational concepts of networking in the OSI model that you have mentioned in your post are just admirable. I had some problems with the tagged and untagged things; Good news is that I just sort it out! Thanks once again.
Are you 100% positively sure that this part of your explanation is without error?
“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.”
I examine this througly and I am sure that VLAN 10 and VLAN 20 are not in the same position. Please do review once more that part of text because it is source of many confusion for beginners right now.
You’re right, the wording is backward. I’ll edit the text. Thank you!
Are you 100% positively sure that this part of your explanation is without error?
“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.”
I examine this througly and I am sure that VLAN 10 and VLAN 20 are not in the same position. Please do review once more that part of text because it is source of many confusion for beginners right now.
Great article!
Only part I’m confused about is the Hyper-V VLANS section, it’s quite confusing, whereas the previous parts were explained in a much more simpler and friendly fashion.
What doesn’t make sense?
Hi Eric,
I’m confused about the entire Hyper-V VLANs section. It’s a bit confusing to conceptualize everything. Would you be able to provide some diagrams or screenshots of what you’re referencing?
For example, you wrote:
“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 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.”
But my understanding is that you CAN in fact configure it? Here’s a screenshot:
http://www.serverwatch.com/imagesvr_ce/1211/vswitch-manager-1.png
The other points you’ve made are this:
“This just means that Hyper-V isn’t going to be able to strip VLAN ID’s from traffic leaving virtual machines.”
“Just leave the VLAN ID off of any virtual adapter you want to receive from the incoming switch’s native VLAN ID.”
I’m confused because those 2 points contradict each other? As far as I understand, you set the VLAN ID for the virtual machines here:
http://blogs.technet.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-94-09-metablogapi/6708.VLANHyperV01_5F00_3AFC115D.png
So if you then remove the VLAN ID, wouldn’t that break the VM, because it’s not running on the specific VLAN anymore?
Hi Eric,
Regarding this paragraph again:
“When the Hyper-V virtual switch takes over a physical network adapter, that network adapter become an “uplink”. The big thing to be aware of is that we don’t, and can’t, configure this particular trunk “port” in Hyper-V.”
That is for a virtual NIC, not the physical NIC.
Your first screenshot is for a virtual adapter that the management OS uses. That’s not the switch’s trunk connector.
No switch accepts VLAN-tagged packets from ports in access mode. That includes Hyper-V. If a virtual machine connected in access mode sends a packet with an 802.1q tag, a regular switch will drop it. I don’t know exactly what Hyper-V does, but it won’t process it as tagged traffic.
At no time does any port in access mode ever have a VLAN tag. The switch knows which ports belong to which VLANs and handles them entirely without the usage of tags in the Ethernet frame. To not do so would facilitate a breakout attack.
Thanks for your reply Eric. I think I’m slowly getting it, but still a bit confused about some parts.
“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 IDs from traffic leaving the virtual machines.”
– Ok, so some VMs may be assigned a VLAN ID. Traffic leaving these VMs won’t have their VLAN ID removed.
“Just leave the VLAN ID off any virtual adapter that you want to receive from the incoming switch’s native VLAN ID.”
– Wait, didn’t you just mention above that you can’t configure a native VLAN on a virtual switch? This contradicts the above?
Another question…
In your graph showing the connected switches, why is it that the Cisco switch has VLAN 10, 20 and 30 in the allowed list, but the Netgear switch only has VLAN 20 and 30 in the allowed list?
I read your other article here:
http://www.altaro.com/hyper-v/vlan-trunking-for-hyper-v-guests/
Looks like you can actually configure trunks on a virtual switch using SCVMM?
Great article!
Only part I’m confused about is the Hyper-V VLANS section, it’s quite confusing, whereas the previous parts were explained in a much more simpler and friendly fashion.
Just noticed something else too…
In the Cisco/Netgear switch example, VLAN10 traffic is untagged. So the frames sent across the two switches will not require a 802.1q tag of 10.
In the case for a virtual switch, how will that work? Hyper-V will accept incoming untagged traffic from the Netgear switch, that’s fine. However, because the traffic is untagged, the virtual switch doesn’t forward it to the VMs on VLAN10. Does that mean we need to remove the VLAN on the VM then? But by removing the VLAN from the VM, we may run into this issue:
http://serverfault.com/questions/587595/hyper-v-2012-r2-nic-teaming-with-vlans
Just noticed something else too…
In the Cisco/Netgear switch example, VLAN10 traffic is untagged. So the frames sent across the two switches will not require a 802.1q tag of 10.
In the case for a virtual switch, how will that work? Hyper-V will accept incoming untagged traffic from the Netgear switch, that’s fine. However, because the traffic is untagged, the virtual switch doesn’t forward it to the VMs on VLAN10. Does that mean we need to remove the VLAN on the VM then? But by removing the VLAN from the VM, we may run into this issue:
http://serverfault.com/questions/587595/hyper-v-2012-r2-nic-teaming-with-vlans
“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. ”
Hi Eric, don’t quite understand this part.
Traffic for a native/untagged VLAN travel between switches WITHOUT a 802.1q tag, correct? So if there’s no VLAN ID associated with the frame, what is there to strip anyway?
Also, were you referring to traffic leaving the VMs on the host where the virtual switch resides?
Oh wait I think I understand your wording now.
Using the same example, VLAN10 is set as the untagged VLAN for the Netgear switch. If traffic on VLAN10 on the Cisco switch were to be sent across to the Netgear switch, the process will be something like this:
1) Cisco switch removes 802.1q tag of 10.
2) Netgear switch receives untagged traffic (designated for VLAN10).
However, for a virtual switch in Hyper-V, native/untagged VLAN isn’t supported. Therefore, the process becomes:
1) 802.1q tag of 10 does not get removed from VM traffic by Hyper-V.
2) Hyper-V Virtual Switch sends traffic to Netgear switch.
3) Netgear switch receives frames designated for VLAN10.
There’s still a problem with this though. In your example, you did not specify VLAN10 to be in the tagged list on the Netgear switch.
True, that’s not clear. This article is scheduled for a rewrite and we’ll clean this all up.
Awesome, looking forward to it! When will we expect a new rewrite if you don’t mind me asking?
Did what I say make sense to you? I hope I’ve understood the concept.
When a packet arrives on a switch’s trunk port with all 0’s in the VLAN segment, then the switch processes it as being a member of its native/untagged VLAN. That section is always present on a packet that crosses trunk ports.
“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. ”
Hi Eric, don’t quite understand this part.
Traffic for a native/untagged VLAN travel between switches WITHOUT a 802.1q tag, correct? So if there’s no VLAN ID associated with the frame, what is there to strip anyway?
Also, were you referring to traffic leaving the VMs on the host where the virtual switch resides?
Oh wait I think I understand your wording now.
Using the same example, VLAN10 is set as the untagged VLAN for the Netgear switch. If traffic on VLAN10 on the Cisco switch were to be sent across to the Netgear switch, the process will be something like this:
1) Cisco switch removes 802.1q tag of 10.
2) Netgear switch receives untagged traffic (designated for VLAN10).
However, for a virtual switch in Hyper-V, native/untagged VLAN isn’t supported. Therefore, the process becomes:
1) 802.1q tag of 10 does not get removed from VM traffic by Hyper-V.
2) Hyper-V Virtual Switch sends traffic to Netgear switch.
3) Netgear switch receives frames designated for VLAN10.
There’s still a problem with this though. In your example, you did not specify VLAN10 to be in the tagged list on the Netgear switch.
Great article Eric, just one question…
“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.”
Makes sense, considering in your Native VLAN section, you mentioned this:
“All incoming frames without a tag are treated as members of this VLAN.”
So say a server or a VM without any VLAN assigned, sends traffic out somewhere. The virtual switch will forward the traffic without assigning a 802.1q tag, to the connected switch. The connected switch (e.g a Netgear switch) has VLAN10 configured as the untagged VLAN, but will accept this traffic anyway, because the traffic does not have a tag.
My question is, what about the ports that are set as Access Mode on the Netgear switch? They communicate using untagged frames. Am I right to think that once the untagged VLAN receives the traffic, it will forward to all ports that do not have any VLANs assigned?
The frames that pass on access mode ports do not have an 802.1q tag section in the Ethernet header. That is the difference between access mode and trunk mode. The switch ensures that traffic inbound from an access port is retransmitted to the proper destination ports. There’s really no such thing as no VLAN on any VLAN-capable switch. Everyone is a member of at least one VLAN. On a real Netgear switch, that is VLAN 1.
I think the key concepts can be summarized as follows:
– Access Mode ports will communicate using untagged frames on the same VLAN.
– When incoming tagged packets arrive at the switch’s Trunk port, the tag is removed and the switch will forward the untagged packet to the correct Access Mode port(s) based on the VLAN. But again, the tag is already removed, so the Access Mode ports will receive untagged frames. The switch just knows what ports to forward to.
– Untagged frames arriving into the Trunk port are technically still tagged. They just have all 0’s in the VLAN segment instead of an actual VLAN ID. These untagged packets will be placed in the native VLAN.
– There can only be one native VLAN configured on a physical switch. In the case of a virtual switch, you can’t configure one. However, native VLAN still exists, just without a specific VLAN assigned. It’ll just accept all untagged packets. – “All incoming frames without a tag are treated as members of this VLAN.”
– If you want a VM (connected to a virtual switch) to receive untagged traffic, just don’t configure a VLAN on the VM. However, I don’t really agree with this because I’ve read a Microsoft documentation that it must be configured? As you’ve mentioned in one of the comments, “There’s really no such thing as no VLAN on any VLAN-capable switch. Everyone is a member of at least one VLAN”. So I would imagine that a VM needs to be part of some VLAN to communicate on the network.
Great article Eric, just one question…
“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.”
Makes sense, considering in your Native VLAN section, you mentioned this:
“All incoming frames without a tag are treated as members of this VLAN.”
So say a server or a VM without any VLAN assigned, sends traffic out somewhere. The virtual switch will forward the traffic without assigning a 802.1q tag, to the connected switch. The connected switch (e.g a Netgear switch) has VLAN10 configured as the untagged VLAN, but will accept this traffic anyway, because the traffic does not have a tag.
My question is, what about the ports that are set as Access Mode on the Netgear switch? They communicate using untagged frames. Am I right to think that once the untagged VLAN receives the traffic, it will forward to all ports that do not have any VLANs assigned?
I’ve been reading up articles left and right and now I’m super confused.
In the native VLAN section, it says:
“…..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.”
OK, I get that. But then I found this Technet article here:
http://blogs.technet.com/b/keithmayer/archive/2012/11/20/vlan-tricks-with-nic-teaming-in-windows-server-2012.aspx
And it says this:
“By using the “switchport trunk native vlan 2” command, it causes all native traffic to be passed across the trunk with a VLAN ID 2 tag.”
So one source says native VLAN passed across the trunk will not have a tag, the other says it will have a tag. Both are valid sources, so I don’t know which one is correct/wrong.
The 802.1q tag is always present on every frame that passes across a trunk. If it’s in the native VLAN, then the tag is all zeroes. The second sentence is phrased very, very badly. “switchport trunk native vlan 2” means that incoming all-zero packets will be sent to local ports in VLAN 2 and that packets sent off the switch from VLAN 2 will have an all-zero tag.
right, that definitely makes much more sense!
I’ve been reading up articles left and right and now I’m super confused.
In the native VLAN section, it says:
“…..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.”
OK, I get that. But then I found this Technet article here:
http://blogs.technet.com/b/keithmayer/archive/2012/11/20/vlan-tricks-with-nic-teaming-in-windows-server-2012.aspx
And it says this:
“By using the “switchport trunk native vlan 2” command, it causes all native traffic to be passed across the trunk with a VLAN ID 2 tag.”
So one source says native VLAN passed across the trunk will not have a tag, the other says it will have a tag. Both are valid sources, so I don’t know which one is correct/wrong.
The native VLAN is not setting an 802.1q Tag it is telling the trunk that UNTAGGED packets belong to VLAN 2.
the native VLAN is always – UNTAGGED and is equivalent to the PVID.
Careful there. You’ve made a good conceptual comparison, but it’s literally false. In action, the native VLAN and PVID are oppositional, not equivalent. Setting PVID on a port excludes it from the native VLAN.
But, to say that the native VLAN is to the switch as the PVID is to a port, that would be a fairly solid analogy.
Now we have windows 2016 servers, and PowerShell cmdlet Set-VMNetworkAdapterVlan can set the virtual adapter to be a promicuous, isolated and community port for each VM. Now, in an environment where these VMs need to get internet access under PVLAN configuration, how can be set up the uplink port to communicate to the physical switch? I mean, the virtual switch can be set smoothly under PVLAN configuration to communicate down and between VMs using their specific virtual network adapter (which includes the virtual NIC for the VM and the virtual switch “port”) but there’s no configurable uplink “port” to connect the virtual switch to the physical NIC of the host and then connect to the physical siwtch. How logically works the virtual switch specifically when it is assigned to a physical interface of the host server? Does the physical host NIC act as the uplink port? Should the physical host NIC (which is assigned to the virtual switch) be configured with the VLAN tag according to the primary VLAN ID set on the promiscuous port of the physical switch? Give me some light please. Regards.
The virtual switch completely consumes the physical NIC(s) and essentially becomes a transparent trunked pathway. If you’re just starting out, start here: https://www.altaro.com/hyper-v/simple-guide-hyper-v-networking/. After that, or if you have a bit of experience, see here: https://www.altaro.com/hyper-v/the-hyper-v-virtual-switch-explained-part-1/. Make certain that you understand all of that before moving into VLANs.
I recommend that you avoid setting a VLAN ID on a physical NIC. It can be done, but usually does not work out the way that you want and becomes a management problem.
I’m unclear from your usage if you intend PVLAN to mean private VLAN or if you intend it to mean port VLAN as in the article. Since you also used “promiscuous”, I’m assuming that you mean private VLANs. I have not worked with those in some time, but I believe that you only need to configure the VMs’ virtual NICs so that their primary VLAN matches the switchport’s promiscuous VLAN and then the private VLAN is whatever you need it to be.