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 4)
Introduction
So far in this article series, I have spent quite a bit of time talking about the basic concepts and benefits of software defined networking. In this article, I want to continue the discussion by introducing some of the most important concepts that you will need to understand prior to building software defined networks.
Network Types
The first concept that you will need to understand in order to comprehend software defined networking for Hyper-V virtual machines is the fact that software defined networking makes use of three different network types. The first network type is the physical network. The physical network consists of physical networking hardware that provides connectivity to the physical devices on your network.
The second type of network that is used is the Hyper-V virtual network. The Hyper-V virtual network should be familiar to anyone who has experience with setting up Hyper-V virtual machines.
Hyper-V virtual networking is based around the use of a virtual switch. There are three different types of virtual switches – External, Internal, and Private. For the sake of this discussion, I am going to focus solely on external virtual switches since they are the virtual switch type that is the most commonly used.
An external virtual switch is bound to a physical network adapter within the host server. Virtual machines do not connect directly to the physical network adapter. Instead, they are connected to the virtual switch, and the virtual switch passes packets between the virtual machines and the physical network.
The host operating system also makes use of the virtual switch. Rather than the host operating system communicating directly with the physical network adapter, Hyper-V creates a virtual network adapter for the host operating system. This allows communications from the host operating system to pass through the virtual switch.
The third type of network that is used in software defined networking is the logical network. Logical networks kind of fall somewhere in between virtual networks and physical networks. Logical networks are constructed through System Center Virtual Machine Manager and typically mimic the underlying physical network. Logical networks make it possible to have a layer of abstraction from the physical network.
It is important to understand that the network types that I have just discussed are commonly used as mechanisms for creating isolated virtual networks. For example, an organization might create an isolated management network and perhaps some isolated tenant networks.
Of course this raises the question of how networks that share common physical hardware can be securely isolated from one another. As I explained in the first article in this series, logical isolation is nothing new. VLANs have been providing isolation for decades by defining virtual networks with a VLAN identifier.
Software defined networks use a somewhat similar approach, but do things a little bit differently. Before I explain exactly how isolation works, I want to give you an example of another type of isolation that might help put things into prospective.
About 20 years ago, I decided to build a home network. At the time I knew that I wanted to use TCP/IP on my network, but I was really new to TCP/IP and didn’t completely understand how IP address assignments worked. Since I couldn’t figure out where I was supposed to get addresses to use on my network, I picked a random address space.
As strange as it may sound, I am still using my chosen address space today. I guess there was just never a good time to reassign all of the addresses on my network, so I kept using the address space that I had chosen so long ago.
Now here is where things get interesting. My randomly chosen address space actually ended up belonging to an ISP in France. Even so, I am still able to use it without causing any problems for myself or for the legitimate owner of the address space. So why is that?
It is because my home network is on an isolated subnet. Sure, I have Internet connectivity, but my router obscures the addresses that I am using internally from being seen by the outside world. My ISP has assigned me a static IP address, and I in turn assigned that address to my router. My router acts as a NAT device that facilitates communications between my private network and the Internet. The exact same principle would apply if I had used a private address space such as 192.168.0.x.
OK, so what does all of this have to do with Hyper-V and software defined networking? Well, as I explained, I am able to use a set of addresses on my private network that I really should not be using because those addresses are confined to an isolated subnet. The same concept applies to Hyper-V software defined networks. Address spaces are isolated within virtual subnets. This is why it is possible for tenant networks to use overlapping address spaces without causing problems for one another.
So how is it possible to create isolated, and yet potentially overlapping subnets that share a common set of hardware? The answer is that Hyper-V network virtualization makes use of encapsulation.
The encapsulation process really isn’t all that different from what is used on virtual private networks (VPNs). VPNs use packet encapsulation as a way of passing private network traffic securely across the Internet. When a packet needs to be sent across a VPN, an Internet facing endpoint adds a layer of encapsulation that allows the packet to be sent across the Internet to a remote VPN gateway. Upon receiving such a packet, the VPN gateway strips off the encapsulation and forwards the packet to a host on the remote network.
Hyper-V virtual networking uses a somewhat similar method of encapsulation to prevent virtual networks from interfering with one another on the physical network. You can actually see elements of the encapsulation through PowerShell.
Microsoft provides a PowerShell cmdlet called Get-NetVirtualizationLookupRecord. This cmdlet returns a number of different pieces of information, but there are a few attributes within the results that are particularly interesting.
The first things that you might notice when looking at the results are the virtual machine name (VMName) and the Customer Address attributes. These attributes list the virtual machine name and the IP address that has been assigned to the virtual machine.
What is more interesting however, is the VirtualSubnetID attribute. This attribute displays an eight digit number that uniquely identified the subnet. Virtual machines that share a virtual subnet ID share a common virtual network. If two virtual machines have different virtual subnet IDs then they are on different virtual networks. Virtual machines with dissimilar virtual subnet IDs can use the same customer address (the IP address that the tenant assigns to the VM) because the virtual networks are isolated from one another.
Incidentally, in multi-tenant environments, each tenant is assigned a unique customer ID. This makes it possible to track who each virtual network belongs to. The CustomerID attribute is exposed through the Get-NetVirtualizationLookupRecord. I plan to cover this cmdlet in more detail later in the series.
Conclusion
In this article, I have explained that network virtualization is based around the use of encapsulation. In the next article in this series, I plan to explain the roles played by the HNV gateway and by System Center Virtual Machine Manager.
If you would like to read the other parts in this article series please go to:
