A few months ago I was scrambling around trying to locate documentation on this feature called “VLAN” trunking. You see, we had this environment that we did our engineering testing in that consisted of multiple VLANs all serving various purposes and we needed an efficient way to get VMs on the network and communicating with ease. The key was simple – which the implementation we were using meant that for each host to have connectivity across multiple VLANs we had to have multiple NICs in the hosts. This isn’t a problem if you have 2 VLANs, but it gets a bit tricky if you have 12.
In today’s post, I thought I would share with everyone how we got Virtual Lan trunking working in our engineering environment (e.g. lab). This is a rather simple task in the long run but the guidance is spotty at best and a bit confusing to some Server admininistrators at first.
Layer 3: Let the Router be the Trunk Master
The first step is to buy your network “guy” a 6-pack of there favorite cold beer. Prior to beer number 3 and never after beer number 4, ask them to do the following for your router\switch interface that feeds your Hyper-V host:
That’s it – your VLANs should be broadcasting to all connected to that interface and ports. To simplify, here is a snippet from one of our switches – my suggestion, show this to your “network” guy and say make us look like this.
NOTE: Credit goes out to my main man Nick Payton – proud new father who worked with me to get this working at Layer 3. Nick rocks!
Windows Server 2008 Host – No IP Address… Come On Man
The tricky step is after your network guy gets to beer 4 and says “Done!” and says go at it “server” boy. As the person who experienced this first-hand, I had to step back and say ok … what do I do here. The first thing to learn is that all that you have been taught goes to the wastebasket about configuring the IP layer at the server. This isn’t done when you are actually using VLANs as you “typically” want the NIC plugged into the interface above (e.g. gig 1/1) to pass-through the VLANs to the Virtual Machines.
To do this, do the following:
- On your Hyper-V host, validate that you have connectivity on the NIC that is connected to the interface above
- Right-click on this network, select properties (Windows Server 2008) or clicked Advanced Adapter settings in Windows 2008 R2
- Verify no configuration settings for the NIC’s adapter nor for the IP settings
- For Windows Server 2008 R2, the ideal method for performance purposes is to isolate the VLAN NIC to not get shared with the Operating System
Preferred:As for Hyper-V host, this is it. There should be no use of VLAN identification and the NIC binding for the Virtual Network should connect to the VLAN NIC. In neither the physical NIC configuration (see screenshot below) nor in the Hyper-V Virtual Network Manager should a VLAN be included.
Configuring VM’s to use VLANs
The final step in enabling VLAN trunking is to configure the Virtual Machine in Hyper-V to use the VLAN id. The one thing that we do in our environment is to make sure that we have DHCP on each of our VLANs otherwise it is difficult to verify that layer 3 is working in the VM. It is easier to set a static to a machine who you know is working (due to DHCP) than to set one that you are unsure if you used a bad IP, etc. (R2’s validate settings on exit feature is nice for helping this out)
The steps to enable the VM to use the VLAN in your environment are the following:
- Create your New Virtual Machine
- On the Connection selection screen, select the Virtual Network that is trunked from above
- After completing the creation of the Virtual Machine, right-click the VM in Hyper-V console and select settings
- In the properties of the Virtual Machine, select the Enable virtual LAN identification by checking the box. Input the VLAN id (e.g. 302) in the text box
Why the heck does this matter? Imagine having 12 VLANs in your infrastructure – Prod, Staging, UAT, DEV and each of these has various “environments” associated for a total of 12 network segments identified by one switch but with 12 VLANs. Each VLAN doesn’t have any access to the other (blocked at Layer 3). The choices you have is several Hyper-V hosts serving various different environments *or* you would need a lot of physical NICs in your host with a whole lot of cabling to the switch.
Why manage a spider Web of cables when you can easily manage a single port on a switch connected to a single port on the server and have all 12 VLANs available to the Hyper-V host.
It’s easy, it’s simple… it’s just different. Network guy meet Server guy, Server guy meet Network guy… It’s a VLAN match made in heaven. Sorry – couldn’t resist!