Microsoft Subnet An independent Microsoft community View more

Virtual Networks in Windows 2012 and Azure VMs

Today's Foundational Building Blocks for a Microsoft-based Private and Public Cloud Environment.

This article addresses a key function built in to Windows 2012 that on first blush may seem like a complex technical networking feature, but that functionality has GREAT implications when extending your on-premise Windows to the cloud (like Azure VMs). You don't recognize the value of Virtual Networking in Windows 2012 until you truly start to see where the functionality is CORE to an organization that in a few years (or sooner) have servers on-premise as well as in the cloud. Given the direction of most organizations networks, that is basically ALL organizations in a very short period of time. AND, this functionality built in to Windows completely changes the competitive advantage Microsoft has when it comes to having servers both on-premise as well as in the cloud.So here’s the deal…with Windows 2012, Microsoft included a thing called "Network Virtualization" that basically allows you to create a Virtual Local Area Network (VLAN) without having to buy VLAN hardware, setup complicated appliances, use a third-party product (ie: Cisco, Brocade, etc.) to create these virtual networks. The benefit of VLANs is to isolate traffic, so if you have your finance department that wants to be the ONLY ones to access a finance server/application, you can create a VLAN between finance users and the VM/app! This becomes important when virtual servers are in play because if you have, say, 10 virtual guest sessions running on a single host server, and 12 VMs on another server, and say 8 on a third server, but a VM on each "host" should be "grouped together" so the finance department can access the 3 VMs without anyone else in the org accessing those servers, you would create a VLAN between the finance users and the VMs on each host server. Makes sense…I've seen organizations use this functionality in Lab environments by giving individuals access to specific guest sessions in a shared lab environment and ensuring each user can only access their virtual guest sessions via these dedicated VLANs (network virtualization segment). With this separation, users can ensure others cannot access their guest sessions, users can run the same Active Directory Domain name across multiple sets of VLANs so that the domain name on one group of servers does not crash in the guest sessions of another group of servers using the same domain name.So creating virtual networks on-premise has a huge benefit for isolation of communications on-premise. For more information on the concepts of Network Virtualization in Windows 2012 and how to configure an on-premise VLAN using Windows 2012, see this TechNet article.In the article, as represented in the graphic below, you’ll be able to see conceptually how the host servers have a physical IP address (192.168.1.x) and each of the guest VMs have been given what is called a "container address" (10.1.1.x) that isolates the traffic across VMs. This is all done through a new protocol (VMGRE) which is a Virtual Machine extension of the Generic Routing Encapsulation (GRE) commonly used in Corporate networks. VMGRE was developed between Microsoft, Intel, Dell, HP, Emulex, and Broadcom and has been submitted as RFC 2784 and RFC 2890.

previous blog post. With Azure VMs, you can build your own Windows 2008 or 2012 guest session in the cloud and load up software on that cloud-based virtual guest session. Give it a try, it only takes 30-minutes to build out and its free to fiddle…So while you can create a HyperV VM in Azure in the cloud, how do you let that cloud VM “join” your in-house Corporate network and basically extend your corporate network to the cloud? The answer is to create a Virtual Network extending your on-prem to the cloud. It's taking the same Windows 2012 Virtual Network concept mentioned above in an on-premise environment to extend your corporate network security to your Azure VM in the cloud.There’s a really good article on the step-by-step process of creating the virtual network on-premise and in Azure VMs. Effectively, a VLAN is created between your on-premise Corp network and Azure VMs to make them all work together as if the VMs in Azure were actually inside your corporate datacenter.While fiddling with the extension of the Corporate network to Azure VMs, you may want the ability to define networks on Azure using a subnet of your choosing, so effectively just extending your Corporate IP subnet to include the Azure Virtual Machine in the cloud. Microsoft calls this a "Gateway Subnet." I found an article that clarifies this Gateway Subnet in more detail on how a Corporate IP subnet can be extended to Azure VMs so that the Azure VMs can be part of the Corporate network…

Using this scenario, not only can you do Network Virtualization and stretch your Corporate network to the Azure VM network, but the IP addresses within Azure can be set to whatever you want them to be to match your internal corporate network IP address scheme, so an extension of the Virtual Networking piece.Okay, so this is all that is available “right now” with Windows 2012/Azure VMs/Virtual Networks/Gateway Subnets…So where is this all heading? I can build a VM on-premise, I can build a virtual network on-premise, I can build a VM in the cloud, I can extend my Corporate network to include the VM in the cloud, and I can do this all with simple keyclicks in Microsoft Hyper-V and in the Azure Virtual Machine management interface. I don't need to go to my LAN/WAN networking guy to create a VLAN on our Cisco or other hardware that I am then limited to connect to the cloud. As a Microsoft network admin, I can do that all with a simple keyclick and configuration fo the VM.AND, what's even better, if you had to failover guest sessions between Hyper-V host servers, like doing a Live Migration failover between hosts, OR if I wanted to do disaster recovery between my on-premise guest sessions and my Azure VM guest sessions in the cloud, I can fail stuff over AND completely maintain my network connectivity between VMs on-premise and in the cloud. Try to do that SEAMLESSLY using VMware and your internetworking vendor VLAN configurations! By integrating the Windows guest session (Windows 2012), the Windows hypervisor (HyperV), the Windows guest in the cloud (Azure VM), leveraging a COMMON network VLAN communications, everything is all seamlessly configured, connected, fail forward, fail backward.It's no longer the game where VMware is a great hypervisor, or your VLAN appliance and internetworking equipment does network routing and segmentation, it's putting it together so that you can completely connect on-prem servers, on-prem guests, and cloud-guests together and move stuff around as you see fit!Start with the following: 

Okay, so roll this forward 1 step where this REALLY starts to get better…so you can create a VLAN within a network, but the real benefit is creating a VLAN to the cloud, so like to Microsoft's Azure Virtual Machines (VMs). I’ve addressed creating an Azure Virtual Machine in a

1) fiddle with Windows 2012 Virtual Networking across a couple Hyper-V host servers, that'll allow you to create a mini-VLAN to segment communications between hosts in-house. The step by step process is outlined in the first link above.2) then once you have the VLAN setup and working in-house, build yourself an Azure VM in the cloud with the steps I note off my previous Network World blog post on Azure VM creation.3) With an Azure VM created in the cloud, connect that VM back to your corporate network using the Virtual Networking referenced in the 3rd link above that'll give you a connection between your on-premise hyper-v guests and your cloud-based Azure VMsHopefully, this all makes sense and you can start seeing why Windows 2012, Hyper-V, and Azure VMs completely blows away any other solution in the marketplace, and it does it all "in the box"!

Insider Shootout: Best security tools for small business
Editors' Picks
Join the discussion
Be the first to comment on this article. Our Commenting Policies