In this Petri IT Knowledgebase post I want to give you the information so you can decide if you should use Virtual Local Area Networks (VLANs) or Hyper-V Network Virtualization (HNV) as the means for isolating networks in your Hyper-V deployments.
VLANs were created to allow a layer-2 network to be broken up into multiple broadcast domains. The primary reason for doing this was to control broadcast traffic. A single large flat network was once a very noisy place, with a broadcast packet being sent by clients to locate services. This is mostly a thing of the past in Windows networks, thanks to DNS being an essential components of Active Directory and Internet communications.
There were other benefits to VLANs. The first of which was that creating VLANs allowed network administrators to break up a single physical LAN into multiple subnets. This meant that a single LAN could support multiple subnets, and therefore handle more IP addresses with a shared network core.
A secondary benefit of creating subnets using VLANs was that you could use router or firewall rules to isolate those networks. However, VLANs were never meant to be used or to scale out in the way that we have used them.
A network can support up to 4096 VLANs. That number might sound large, but they disappear quickly once you start to deploy them. Just ask a network administrator in a hosting company where each tenant requires at least one (maybe many) isolated networks. And not only do they disappear quickly, but adding VLANs makes a network core very complex to manage. Firewall administrators sweat bullets whenever they are asked to add VLAN-isolated tenants into a crowded multi-tenant public cloud.
You can use VLANs with Hyper-V virtual machines just as you would with physical servers. A trunk port (or more if using NIC teaming for the virtual switch) is created on the top-of-rack (TOR) or access switch(es). Virtual machines are then tagged with the ID of the VLAN with which you want them to be associated. This is managed by the Hyper-V or System Center administrators.
Using VLANs to isolate virtual machines.
The system is nice and simple; the hard work is done by the network administrator to create the VLANs, configure routing, and define firewall rules. All the Hyper-V administrator needs to do is assign the tag or VLAN ID that is shared by the network administrator.
While this approach is simple, and perfect for small and medium enterprises, it is not scalable and does not lend itself to the self-service or automation that is required in a public or private cloud where network provisioning is a part of the deployment process. In those environments you should consider the alternative: HNV.
I have written previously about Microsoft’s software-defined networking (SDN), Hyper-V Network Virtualization. The benefits of HNV stem from the fact that it is software-defined within the scope of System Center and Windows Server. This means that network administrators do not need to be involved in provisioning networks for tenants, lending itself nicely to automation and service-centric clouds with isolated tenants.
HNV adds a lot of complexity. It does require System Center (Virtual Machine Manager to be precise) and in the real world it requires an NVGRE appliance. Customers with Windows Server and System Center 2012 R2 can use Windows Server VMs on dedicated Hyper-V hosts as NVGRE appliances. Right now, that’s probably the best (economy and scale) solution.
If you are going to deploy HNV to isolate VMs or tenants then you will still need to do deploy VLANs to isolate physical networks. For example, in storage you might need to VLANs for Scale-Out File Server storage or to meet the MPIO requirements of a particular iSCSI SAN manufacturer. You might consider having isolated management and/or backup networks. And you will also need a network for the Provider Address (PA) that is used by the physical connection of a HNV-enabled virtual switch for NVGRE encapsulation and forwarding.
A way of using VLANs and HNV together.
In a small or medium static environment you should use VLANs for tenant isolation. In more dynamic, self-service environments such as a cloud, whether public or private, you should use VLANs for physical networks, and use HNV to isolate the tenant networks.