If you would like to be notified when Brien Posey releases the next part in this article series please sign up to our VirtualizationAdmin.com Real-Time Article Update newsletter.
If you would like to read the other parts in this article series please go to:
- What You Need to Know About Software Defined Networking in Hyper-V (Part 1)
- What You Need to Know About Software Defined Networking in Hyper-V (Part 2)
- What You Need to Know About Software Defined Networking in Hyper-V (Part 3)
In my previous article in this series, I talked about the role that encapsulation plays with regard to Hyper-V network virtualization. In this article, I want to continue the discussion by talking about routing within Hyper-V Virtual Networks.
As I previously explained, one of the major benefits to Hyper-V network virtualization is that it allows for the creation of isolated subnets. The subnets are isolated to the degree that each is treated as a separate network. As such, IP addresses and MAC addresses can be duplicated in multiple subnets without any consequences.
Although it might seem a little bit counterintuitive after everything that I have explained, complete isolation of a subnet isn’t usually desirable. In fact, aside from certain security situations, a virtual network that is totally isolated from the rest of the world probably isn’t going to be all that useful. As such, routing is required to facilitate communications between a Hyper-V virtual network and the Internet.
Of course there are some requirements that must be met by the routing process. For starters, routing must be done in a way that allows the virtual networks to communicate with the Internet, but without allowing them to communicate with one another. Under normal circumstances, one virtual network should not even be able to tell that another virtual network exists. I have often heard the example given that if a cloud service provider were hosting virtual networks for both Coke and Pepsi then security would need to be done in such a way that neither company would know that you were also providing services for their competitors. Never mind the fact that you would also need to make sure that nobody from Coke would be able to tamper with Pepsi’s network or vice versa.
In the past, routing for Hyper-V virtual networks was performed by the Hyper-V virtual switch. Virtual machines that were connected to a virtual switch could communicate with one another. Assuming that the virtual switch was configured to be an external virtual switch, it can also facilitate communications with the Internet. If you needed to create an isolation boundary between virtual networks, you could simply connect the virtual networks to separate virtual switches.
Even though this concept works, it really doesn’t scale very well. Hyper-V virtual switches are still used in Windows Server 2012 R2, but they are not the be-all, end-all mechanism for network connectivity. There is another virtual networking component that can provide routing services for virtual networks.
This component is the Hyper-V Network Virtualization Gateway (for HNV Gateway as Microsoft likes to call it). The HNV Gateway’s job is to act as a bridge for virtual networks. A virtual network can be linked to a physical network (usually as a way of achieving Internet access) or it can provide a link between virtual networks, so as to facilitate communications between two otherwise isolated virtual subnets.
The simplest way to think of the HNV Gateway is to think of it as a router. As I’m sure you know, a router sits between networks and makes decisions pertaining to forwarding packets between those networks. The HNV Gateway does essentially the same thing (plus a few other things that I will talk about later). The biggest difference between the HNV Gateway and a normal router however, is that the Gateway is specifically designed to deal with the encapsulation layer that provides isolation between Hyper-V virtual networks.
HNV Gateway Logistics
Before I talk about all of the wonderful things that the HNV Gateway can do, I want to take a little bit of time and talk about some of the logistics involved in deploying a HNV Gateway.
As you might already know, the HNV Gateway is included with Windows Server 2012 R2. It is a component that you can access in the box, similar to other server roles and features. However, the HNV Gateway is not something that you add directly to your existing Hyper-V hosts. Instead, it is designed to be run inside of a virtual machine. As such, you can almost think of the HNV Gateway as a virtual appliance that acts as a router.
Normally when you set up a virtual machine, that virtual machine is provisioned with a default Gateway address as a part of its IP configuration. This default Gateway address might be supplied manually, or it might come from a DHCP server. In either case, the default Gateway address normally points to a router.
For virtual machines that are on a subnet that is connected to a HNV Gateway, the default Gateway address needs to point to the HNV Gateway. One thing to keep in mind is that every virtual machine within a virtual subnet must use the same default Gateway address. You cannot point some of the virtual machines within a virtual network to one HNV Gateway and the rest of the virtual machines to another.
The virtual machine that is acting as a Gateway must exist within its own dedicated virtual subnet. A Hyper-V host can host multiple HNV Gateway virtual machines, but each of those virtual machines will have to exist within a dedicated virtual subnet. You cannot create a master virtual subnet that holds all of your Gateway virtual machines, nor can you place virtual machines into the same subnet as a Gateway virtual machine.
Although it is possible to create multiple Gateway virtual machines, most of the time doing so is unnecessary. A single Gateway virtual machine can handle multiple virtual machine networks.
With that said, it is important to keep your Gateway virtual machine from becoming a single point of failure. While it is technically possible to run the HNV Gateway on a physical machine, Microsoft specifically recommends running it in a virtual machine so that it can take advantage of Hyper-V’s clustering capabilities.
HNV Gateway Functionality
The last thing that I want to talk about is the various tasks that the HNV gateway can perform. I already mentioned that the Gateway is able to act as a router and forward packets between networks. This is the Gateway’s primary function, but it isn’t it’s only function. The Gateway can also perform Network Address Translation (NAT) functionality, and it can provide load-balancing services as a way of helping to achieve scalability.
In addition, the HNV Gateway is also able to act as a VPN. Point to site VPN services allow a remote user to VPN into a virtual network. The Gateway also offers site to site VPN functionality which can be used to establish connectivity between a virtual network and a remote network (such as a network in a different data center).
Conclusion
As you can see, the HNV Gateway is one of the most important components used in Hyper-V network virtualization. It is this Gateway that keeps Hyper-V and virtual networks from being completely cut off from the rest of the world. Unlike a physical router, the Gateway has been specifically designed to deal with the encapsulation layer that is present in Hyper-V network virtualization.
Now that I have explained the basics of how Hyper-V network virtualization works, I want to begin walking you through a sample deployment so that you can see how to go about setting up your own virtual networks.
If you would like to be notified when Brien Posey releases the next part in this article series please sign up to our VirtualizationAdmin.com Real-Time Article Update newsletter.
If you would like to read the other parts in this article series please go to:
