Windows Server 2012 Network Virtualization and Infrastructure as a Service (IaaS) in an On-Premises and Hosted Private Cloud Infrastructure (Part 2)

If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the first part in this article series please go to Windows Server 2012 Network Virtualization and Infrastructure as a Service (IaaS) in an On-Premises and Hosted Private Cloud Infrastructure (Part 1).

Introduction

In the first part of this two part series, we began the discussion around cloud computing and the increasing challenges that cloud computing puts on the networking components of the cloud infrastructure. We also went over some key concepts in cloud computing, such as the ability to abstract as much of the infrastructure from the applications as possible. It is this abstraction of the hardware from the software that depends on it, which drives the abilities, capabilities and power that you can obtain from the effort that you put into creating and managing a cloud infrastructure.

This time, we’ll finish the discussion by explaining how network virtualization works and hopefully we’ll convince you that this is a good technology that you might want to implement in the future. I want to let you know up front, though, that Microsoft has not yet provided details on how to implement network virtualization, and when they do, it’s likely that it’s going to be a “PowerShell only” solution. Thus, if you’re looking for something easy and fun (like the improvements in Windows Server 2012 networking), you’re not going to find those here (unless you’re a big PowerShell fan). But what I hope you do find is a compelling story around these new approaches to networking that will solve some significant problems in your cloud datacenter.

Many faces of virtualization

Most of us are aware of how server virtualization works: the operating system in the virtual server thinks that it is running on physical hardware, when in fact that operating system is actually connected to virtual devices (software constructs) that appear as physical devices to the virtualized operating system. This enables you to move the virtualized operating system (or virtual machine) from one host virtual server to another host virtual server with no problems, because as long as the virtual servers are presenting the same virtual hardware platform to the virtual operating system, then the virtual machine has no reason to think that it has moved to different hardware.

This has allowed us to do some great things like server consolidation and virtual machine mobility within our private and public clouds. Server virtualization in the last decade has gone from being a hobbyist’s plaything to a time saving and money saving technology that is in almost universal use in corporate datacenters everywhere. But server virtualization is only one example of the power of virtualization.

What about storage virtualization? You could say that a LUN ( Logical Unit Number) is a way to virtualize the physical storage in a SAN. And at the media access control level of the networking layer, we have the concept and implementation of Virtual LANS or VLANS – where you can logically segment the physical network into multiple networks by grouping Ethernet collision domains within a single physical switch.

Layer 3 virtualization

While layer 2 virtualization has been with us for a long time, it seems that the Holy Grail of network virtualization is the ability to virtualize at layer 3 – the network layer. Why would we want to be able to virtualize at layer three? Consider these benefits:

  • Virtual machines can be moved anywhere in the datacenter without having to worry about IP address changes.
  • Virtual machines can be moved to any datacenter that’s run by corporate IT, which could include datacenters that are run on other continents, without having to worry about IP address changes.
  • Virtual machines can be moved from the on-premises private cloud to a hosted private cloud somewhere “out there” on the Internet without having to worry about IP address changes.

Indeed, when you think about what holds you back from virtual machine mobility nirvana, it’s the inability to just plop a virtual machine wherever you like without having to take into account IP addressing information. And the IP addressing changes that might be required are not insignificant, either. If you have a multi-tier application that also has some hard coded dependencies on other services in your organization, then you have to figure out how to deal with the routing and addressing issues that you’ll encounter when you move the virtual machines that participate in a service. Ouch!

But what if you could keep the same IP addresses no matter where those virtual machines might go? Well, that is probably a pipe dream at this time, but who knows, it might be possible in the future. So what can we hope for right now? How about the ability to create virtual machines on your own network and then be able to move them to another network, such as a private cloud hoster’s network, without having to change the IP addressing information on the virtual machines that you want to move to the hoster’s network?

If you think that sounds like a good thing, then the good news for you is that the Windows Server 2012 Network Virtualization feature will enable you to do this. Let’s look at how it works.

How network virtualization works

Network Virtualization enables you to layer virtual networks on top of the physical networks that handle the traffic. In a way, this is similar in concept to what we do with Virtual Private Networks (VPNs) where we abstract the logical networking from the physical networking by tunneling the logical network connection inside the physical network connection.

Imagine that you have a network like the one in the figure below (which was adapted from a blog post on virtual networking).


Figure 1

In this example, the cloud service provider is using network ID 192.168.1.0/24 for the physical network. No problems with that. Now, let’s imagine that the cloud service provider has two customers, the RED customer and the BLUE customer. And now imagine that both customers are using the same network ID on their internal networks (we know this happens all the time because it creates all sorts of problems when having to deal with creating a VPN to a network that is on the same network ID as the one that you’re currently on). What happens?

HOST1:
BLUE-1 10.1.1.7
RED-1   10.1.1.7

HOST1:
BLUE-2
10.1.1.5
RED-2   10.1.1.5

This doesn’t look good at all! The BLUE company and the RED company have virtual machines that have the same IP addresses. On HOST1 they have two virtual machines that have the same IP addresses and on HOST2 they have two virtual machines using the same IP addresses. Without something to help fix this, there will be an IP addressing conflict and that can lead to a number of unwanted consequences.

Never fear; we can fix this by taking advantage of the Windows Server 2012 Network Virtualization. What we will do here is define two network IDs (in this example):

  • An address range that is used by the hosting provider (the Provider Addresses) and
  • An address range that is used by customers or consumers of the cloud service (the Customer Addresses).

The physical network “sees” the Provider Addresses, so the routers, switches and other network gear are aware of these addresses and act on them accordingly. The Customer Addresses are hidden from most of the physical devices and are only seen by those devices that are participating in the Network Virtualization solution.

In this case, it’s the virtualization servers that are aware of what we’re trying to accomplish with Network Virtualization. We do this by mapping the physical addresses on the provider’s network to the virtual addresses on the customers’ networks. Such a mapping might look like this:

HOST1:
BLUE-1 10.1.1.7/192.168.1.10
RED-1   10.1.1.7/192.168.1.11

HOST1:
BLUE-2
10.1.1.5/192.168.1.12
RED-2   10.1.1.5/192.168.1.13

Now there are no addressing conflicts on the physical network. When a device on the cloud service provider’s network needs to send a packet to RED-1, it sends it to IP address 192.168.1.11. When it reaches HOST1, the virtual server knows that when it receives this packet, it should be routed to RED-1 and not BLUE-1, even though they have the same IP address assigned to them. When you combine this IP address mapping capability with the ability to isolate the RED company’s from the BLUE company’s virtual machines (such as by using the Hyper-V Port ACLs or similar solutions), we completely get around the issues of IP addressing conflicts and each company can now keep the addresses it used when developing the virtual machines on premises, when they move them to the cloud service provider’s network.

As you can see, Windows Server 2012 Network Virtualization now enables increased mobility for virtual machines. While we can easily move virtual machines within our own datacenters now, with the new Network Virtualization feature, you will be able to move virtual machines across networks without having to worry about IP addressing issues. The virtual machines just keep the same IP addresses and everything just works. Another nice thing about this Windows Server 2012 feature is that the virtual machines are unaware of the Network Virtualization – just as they are not aware of server virtualization. So you can use any operating system that is supported by Hyper-V as a guest, such as Windows Server 2008 R2 or even Linux.

Implementation approaches

Now you are probably wondering exactly how this is all accomplished. There are two approaches you can use to support Network Virtualization in Windows Server 2012:

  • GRE encapsulation
  • IP address rewrite

Both mechanisms take advantage of a virtual subnet ID. This allows the source and destination hypervisors to differentiate between guests that have the same IP address on the same host.

With GRE, the GRE header contains the virtual subnet ID. What is really cool about using GRE and encoding the virtual subnet ID into the GRE header is that you can use the same Provider Addresses for multiple VMs that might share the same Customer Addresses. Think about that: when you use this method, you won’t ever have to worry about IP address exhaustion in the cloud service provider’s datacenter because you can reuse the same IP addresses over and over and over again!

Of course, it seems as if, whenever you get something really good, there are going to be drawbacks. So what’s the catch? In the case of GRE encapsulation, you lose all the cool hardware offloads that are included in Windows Server 2012, which enable you to get blazing fast wire speed for network communications. What this means is that you will not be able to reach the level of virtual machine density on your host servers that you could have if the network hardware offloads were available. The reason for this is that the packet is hidden from the hardware because it’s encapsulated by the GRE header.

However, in the future Microsoft expects that there will be hardware that is GRE-aware so that server, switch and NIC vendors can back GRE awareness and look inside the encapsulated packet and hardware offloads will become available again.

But what do you do until you can get that hardware? You can take advantage of the IP address rewrite capability in Network Virtualization. IP address rewrite, as the name suggests, rewrites the source and destination IP addresses with the Provider Addresses before they leave the server. When the packets reach the destination server, the destination server knows the Provider/Customer address mapping. This is very similar to the NAT mechanisms that we’ve been using for years and since there is no encapsulation, it works with today’s blazingly fast hardware.

Summary

In this article, we went over the challenges of having servers with the same IP addresses on the same network infrastructure and some methods we can use to solve the problem. By taking advantage of Network Virtualization in Windows Server 2012, you can now move your virtual machines from one network to another and not worry about having to change the IP addressing information on the virtual machines. This enables you to take virtual machine mobility to a new level and gets you closer to the goal of complete abstraction of the workload from the underlying hardware that supports the workload. To wrap it up, we explained how Windows Server 2012 can use two different methods to accomplish this goal: GRE encapsulation and IP address rewrite. Network virtualization is just one of the many useful new features in Windows Server 2012. We’ll be delving into others in upcoming articles.

If you would like to be notified when Deb Shinder releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.

If you would like to read the first part in this article series please go to Windows Server 2012 Network Virtualization and Infrastructure as a Service (IaaS) in an On-Premises and Hosted Private Cloud Infrastructure (Part 1).

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top