Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Is there any way to make Hyper-V's (Hyper-V Server 2008 R2 SP1) networking subsystem ignore VLAN tagging and just accept all packets that the physical NIC accepts? ...hopefully by actually ignoring tagging completely and not via some wildcard setting?

Consider this simplified scenario. You have your Hyper-V host connected to a switch via a single cable; the host has a single VM (guest) running on it. Everything has network connectivity; both the host and guest can get to the Internet, and to each other, via TCP/IP (you can ping, RDP, etc.). Next, someone turns on VLAN tagging in the switch such that all packets traveling through it are tagged with VLAN 2. Your host and guest have now lost all network connectivity.

How can you tell Hyper-V to ignore the fact that incoming packets are now tagged with VLAN 2? They physical NIC is ignoring the tagging just fine, so can Hyper-V do it also?

Backstory

So here's the situation. I've got a switch divided into 2 distinct collision domains, but it was done by setting up a VLAN because I had no other choice. The Hyper-V host is physically plugged into one port on one of those collision domains; the host and all VMs are expected to work within that same collision domain. Nothing except the switch has any sort of VLAN configuration; all connected machines behave simply as if there were 2 independent "dumb" switches being used. I would like it to remain this way.

However, in Hyper-V Manager, when I go into the "Virtual Network Manager" dialog to add a new External (physical) interface, if I don't choose the proper VLAN ID (for the host/"parent partition"), the NIC loses all network connectivity. That's because while the physical NIC doesn't care, the new Microsoft Virtual Switch does---and dutifully drops the packets. ...and each VM also has to have the same VLAN ID configured or the VM can't get a network connection.

(FYI, this particular "gotcha" caused untold torment because there's no reporting of such activity anywhere in Hyper-V, and its out-of-the-box behavior is exactly opposite of what physical NICs do.)

Edit: Attempted to clarify my "backstory" and added a simplified example scenario.

share|improve this question
    
I'm not sure I understand - how is it supposed to have VMs on both broadcast domains if it's stripping all tags? –  Shane Madden Jan 12 '12 at 19:39
    
The Hyper-V host machine (and all VMs it hosts) are all only on a single broadcast domain. –  Granger Jan 14 '12 at 15:31
    
But the packets that it's getting are tagged? –  Shane Madden Jan 14 '12 at 15:57
    
Yes. I've added a scenario above that should clear things up. –  Granger Jan 14 '12 at 16:20

2 Answers 2

Is the upstream physical switch port set to a trunk? It shouldn't be sending tagged traffic unless it is, or if it's explicitly configured to do so. If you could convince the admin of the physical switch to set the native vlan on the port to 2, your upstream traffic would make it there correctly, but you're still probably going to receive tagged traffic downstream.

My opinion: You're wasting time. If you're receiving tagged traffic, then you should just configured the right tag on all required ports physical or virtual on the HyperV host and call it a day. With 10 VM's this would take me all of about 15 seconds on a VMware machine, I can't imagine HyperV taking much more effort. Good luck finding a solution to it they way you WANT it, but I doubt it's going to happen.

share|improve this answer
    
If its configured as an access port on VLAN 2, the machine attached has no way to know what VLAN it is on, and it will work as expected. Upstream and downstream don't matter for the VLAN tagging. –  Bill Weiss Jan 14 '12 at 17:36
    
Yes, that's what I said above. Different switch manufacturer's treat the native vlan behavior differently. You can get asymmetric tagging pretty easily with JunOS, where it accepts untagged packets onto VLAN2, but sends tagged packets back if that VLAN is assigned as a member of the trunk. All good fun :) –  SpacemanSpiff Jan 14 '12 at 18:18
    
Upstream of the Hyper-V host: it is what it is; packets are tagged. And I already have things working; that wasn't the question. As for the matter of opinion, I think it's a waste of time to have do any configuration at all. –  Granger Jan 14 '12 at 23:42
    
I agree, on a simple host where you have one broadcast network between the hypervisor and VM's, this sucks. It's not your fault the admin is sending you tagged traffic, but it is what it is just like you said :) I think HyperV's configuration and how it interacts with VLANS is complicating this here. –  SpacemanSpiff Jan 15 '12 at 0:48
    
Remember the failure modes and other people's use cases! I would rather have your "inconvenience" of having to do the configuration than have the guests see all tagged packets. A more common use case here is a hyper-v host containing vms from multiple customers where each customer had a vlan. If the switch port was changed from trunk to untagged, I don't want the customers having access to traffic not intended for them. That's much worse than the headache of doing a simple configuration change in your use case. –  longneck Jun 30 '12 at 1:58

Don't tag a VLan ID on the Virtual Network, only the VMs virtual NIC.

share|improve this answer
    
Your attempt at an answer does not make sense. It leads me to believe you didn't understand the question, so I will try to clarify the question. –  Granger Jan 14 '12 at 15:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.