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 2)
- What You Need to Know About Software Defined Networking in Hyper-V (Part 3)
- What You Need to Know About Software Defined Networking in Hyper-V (Part 4)
Introduction
Although the concept of software defined networking might not be universally familiar, it is arguably one of the most important new networking technologies to come along in quite some time. Software defined networking abstracts the logical network from the physical network using a new set of technologies and techniques. In this article series, I will explain why software defined networking is important and how it works in a Hyper-V environment.
Before I Begin
Before I get started, I want to clarify that software defined networking is not unique to Microsoft. Although Microsoft certainly has their own software defined networking features in place, and have a very broad vision for ways in which the technology might be used, they did not invent the concept of software defined networking. VMware and other vendors also support their own flavors of software defined networking. Even so, this article series will focus exclusively on Microsoft technologies.
What is Software Defined Networking?
The concept of software defined networking can be a little bit difficult to grasp at first. The problem is that software defined networking is very similar to other networking technologies that have existed for years. Admittedly, I myself initially had trouble understanding how software defined networking was different from network virtualization. That being the case, I want to spend the bulk of this article articulating the differences between software defined networking and some other network virtualization technologies that are more commonly known.
The first network virtualization technology to receive widespread adoption was probably VLAN tagging. For those who are not familiar with VLAN tagging, it is a networking standard that has been around for many years that allows a physical network to be divided up into a series of logical networks. The logical networks (or virtual networks as they are sometimes referred to) remain isolated from one another even though they share common networking hardware.
The mechanism that allows VLANs to remain separate from one another is a VLAN tag. A VLAN tag is simply a numeric identifier (the VLAN ID) that identifies the logical network on which a particular device should communicate.
Is important to understand that VLANs predate production use of virtual servers or virtual networks. VLANs were intended for use in a physical environment. As such, VLAN support is baked into the networking hardware.
VLAN technology works well enough and has seen wide enough adoption that it has remained a viable option for many years. One of the big problems with VLAN technology however, is that VLANs really don’t scale very well. There are a couple of issues that impact VLAN scalability.
The first of these limitations has to do with the total number of VLANs that can be supported. There is a theoretical limit of 4096 unique VLAN IDs that can be used on a network. However, most of the networking hardware manufacturers impose tighter limits. The practical limit to the number of VLAN IDs that can typically be defined is usually closer to 1000.
Before I talk about the other major limitation to using VLANs, I need to turn my attention for a moment to network virtualization.
Network virtualization is a concept that should be familiar to most Hyper-V administrators. The basic idea is that on a host server there are usually more virtual machines than there are physical network adapters, so a single physical adapter often needs to be shared among multiple virtual machines. Rather than establishing a direct connection between a virtual machine and a physical network adapter, Hyper-V uses the concept of a virtual switch.
Each physical network adapter that has been approved for use by the virtual machines is bound to a dedicated virtual switch. Any virtual machine that needs to be connected to a given physical network adapter must be connected to the virtual switch to which the network adapter is bound.
Of course this is only one type of virtual networking in Hyper-V. It is also possible to create virtual network segments that do not traverse physical networking hardware. These types of virtual network segments are sometimes used as a way of establishing a secure network backbone between virtual servers.
In some ways VLANs and virtual networks are similar. Both apply some level of virtualization to physical networking hardware. In the case of a VLAN, physical network segments are divided up into multiple logical networks. In the case of Hyper-V virtual networking however, the physical networking hardware is not segmented into logical networks, but rather the virtualization infrastructure allows the hardware to be shared among the connected virtual machines.
It is important to understand that in a purely virtualized environment, network virtualization can accomplish the same thing as a VLAN. Rather than using multiple VLAN IDs, an administrator could keep network traffic separate by creating a series of isolated virtual networks. That being the case, network virtualization could in some ways be thought of as a next generation alternative to VLAN tagging.
The problem with this however, is that network virtualization is isolated to the Hyper-V environment. If you want to extend an isolated virtual network to the physical world, then you have to keep track of which network segments are connected to which virtual networks. It’s a really messy process.
The other problem is that just because an organization chooses to begin virtualizing some of their servers, it doesn’t mean that their existing network infrastructure goes away. Often times, an organization may already have an elaborate system of VLANs in place long before they virtualize their first server. Thankfully, Hyper-V supports VLAN tagging and a VLAN can be extended from the physical network to the virtual network.
With that said, I want to go back to my discussion on VLANs. Earlier I said that there were two major disadvantages to VLAN usage. The first was that there are hardware limitations to the total number of VLANs that you can create. The second disadvantage is that because of VLANs were initially designed for physical environments, they tend not to work all that well in virtual environments due to problems with scalability.
These scalability issues don’t have nearly as much to do with the limit to the number of VLAN IDs that can be created as they do with the amount of work involved in making sure that a VLAN is recognized across the entire virtualization infrastructure.
Imagine for instance that a certain virtual server needs to participate in a VLAN. In this type of situation, the physical switch that the host server is connected to needs to be aware of the VLAN. The host server must also have a virtual switch that has been configured for VLAN participation. The VLAN ID must also be applied to the virtual machine’s virtual network adapter.
Obviously this involves a little bit of work, but nothing that is overly burdensome. The problem is that virtual machines are anything but static. It is common for virtual machines to live migrate from one host to another in response to a failure, maintenance needs, host capacity, or any number of other conditions. It is this virtual machine mobility that causes VLANs not to scale well.
In a situation in which live migrations are supported, a VLAN aware virtual switch will have to be created on every host server that could potentially run the virtual machine. Any physical switches that are connected to the various hosts need to be updated as well. It is also common for aggregation switches to provide connectivity between lower level physical switches. If aggregation switches are being used then they too will need to be configured to be VLAN aware.
Conclusion
The point that I am trying to make is that the amount of work involved in supporting VLANs increases exponentially as the Hyper-V infrastructure grows. Next generation private clouds will need to provide an unprecedented level of flexibility, while maintaining network isolation in multi tenancy situations. This just isn’t practical when VLANs are used as the network isolation mechanism. Software defined networking offers a far better solution to this problem. I will begin discussing the particulars of software defined networking in Part 2.
If you would like to read the other parts in this article series please go to:
