Network Virtualization

Microsoft Network Virtualization and Multi-Tenancy concept

The traditional physical network isolation implemented using VLANs; and in a traditional Network if the server (VM) move from one subnet to a different subnet, its IP address must change (which causes a service interruption).
Network Virtualization importance come to surface with the explosion of cloud computing, because of the capability to answer requirement of moving VMs to the cloud without modifying the VM’s network configuration and without worrying about what other systems floating in the clouds may share the same address.  That is why considered as a cloud network.

Encapsulated Network Virtualization

Network virtualization provides the capability to run multiple virtual network infrastructures on the same physical network, and each virtual network infrastructure operates as if it is the only virtual network running on the shared network infrastructure.

To make this function, we actually end up with each VM being assigned two IP addresses!

The first of these is the IP address visible inside the VM, which we consider the IP address belonging to the cloud-owning tenant; technically, we will refer to this IP address space as the customer address (CA).

The second IP address is managed by Hyper-V in Windows Server 2012 and is used to allow network packets to pass over the physical network to other Hyper-V servers; technically, we will refer to this IP address space as the provider address (PA).

This approach results in a complete isolation between the IPs utilized by the tenants’ virtual machines in the cloud and the physical networks’ IP address scheme.

To review, each VM has two IP addresses:

Customer Address: The CA is the IP address visible within the virtual machines’ network.
This address can be assigned by the tenant, based on existing infrastructure. The tenant can then pass network traffic within the virtual machine as if it had not been moved to a cloud.
Tenants can potentially create a VPN from the premise infrastructure to the cloud space, and simply extend the address space, similar to a stretched VLAN!

Provider Address: This IP address, visible on the physical network, is assigned by the fabric administrator (datacenter administrator or hoster) and will be based on the physical network infrastructure. The PA is not presented to the virtual machines and is used exclusively on the physical network to transfer network traffic between Hyper-V and other devices participating in the network virtualization.

Network Virtualization Abstraction

With virtualization of memory, disks, and even CPU, no additional investment in hardware or infrastructure was really necessary. It’s exciting that the same is now also true for Hyper-V Network Virtualization, which can be easily deployed into our existing environments.

Because you are now able to assign two IP addresses to each virtual machine, you are actually virtualizing the CA IP address by using the PA IP address when sending networking traffic between Hyper-V hosts. The greatest benefit is that for the physical network, nothing out of the ordinary is occurring; services continue to work untouched, business as usual.

As a bonus, Microsoft has enabled Window Server Hyper-V 2012 to support no less than two abstraction methods: Generic Routing Encapsulation (GRE) and IP Rewrite (NAT).

In the majority of environments, GRE should be used for network virtualization, because it provides the highest flexibility and performance. IP Rewrite (NAT) is primarily targeted to provide performance and compatibility in some current high-capacity datacenters but is almost unmanageable in a dynamic environment without any management tools.

Network Virtualization Stack

To better understand the isolation of the CAs and PAs, you need to visualize the concept,

ITMug Cloud Network

Network Virtualization and Multi-Tenancy concept

Let’s consider The IP address assigned to virtual network interface for the virtual machines is a Customer Address (CA).

And The IP address assigned to network interface for the Host machine’s is a provider address (PA).

ITMug_Cloud Network 2

Notice that SmartIT Company is using the same IP addresses that ITMug Company is using.

In a traditional virtual network this will immediately result in IP conflicts on virtual machines. However, the Microsoft Network Virtualization feature has another interesting capability, which will prevent this conflict

Microsoft Network Virtualization enables us to segregate these associated virtual subnets through the concept of Routing Domains.
A routing domain defines a simple relationship between each of the virtual subnets (domain).
Routing Domains, as the network virtualization stack; it will enables Layer 3 routing between these domains, automatically by creating a virtual router! This router cannot be disabled, or even configured

ITMug Cloud Network 3

Note: each domain (company) may have more than one network (for example, Production and Preproduction)

1-Each of these domains networks forms an isolation boundary, enabling the virtual machines within that domain network to communicate with each other. Therefore, virtual subnets in the same domain network must not use overlapping IP address prefixes.
2-Each domain network has a routing domain that identifies that network. The routing domain ID (RDID) is assigned by the datacenter administrator

This approach enables tenants (companies) to bring their network topologies to the cloud.

Virtual subnet ID (VSID) and Routing Domain ID (RDID)

Virtual subnet defines a Layer 3 IP subnet and a Layer 2 broadcast domain boundary and is identified with a unique virtual subnet ID (VSID).

Assigning a VSID to the virtual interface of the virtual machine will have a similar effect to placing the virtual machine into a virtual network (VLAN).

When a virtual machine broadcasts a packet, this broadcast is limited to the virtual machines that are attached to switch ports with the same VSID.

Virtual machines located in BLUE Subnet 1 (4501) can have their packets routed or forwarded by the network virtualization module to virtual machines located in BLUE Subnet 2 (4502) and BLUE Subnet 3 (4503).

The routing between these networks is via a default gateway for each virtual subnet, which is implemented by the network virtualization module.

Bonus:
1- Routing between the subnets located within the same customer network (RDID) is enabled by default and cannot be disabled.

2- No routing between virtual subnets located on a different customer network (RDID).

In summary
1-Each virtual machine CA is mapped to a physical host PA.
2-Virtual machines send data packets in the CA space, and use envelopes when the destination is on a different host.
3-The CA-PA mappings must contain enough detail to ensure that the envelope is addressed correctly to reach the correct customer and destination address.

Envelopes of Data

Microsoft included two address translation mechanisms to implement network virtualization, namely packet encapsulation (GRE) and packet rewrite (NAT).

A) Packet Encapsulation (GRE)

The VM’s packet is encapsulated by using CA IP addresses inside another packet using PA IP addresses, along with a copy of the VSID and the virtual machine’s sending interface MAC address.

 

ITMug_Virtual Network 4

Because of the inclusion of the VSID within the header, we can now identify the company (tenant) owning the virtual machine

B) Packet Rewrite (NAT)

With IP Rewrite, we rewrite the source and destination CA IP addresses in the packet with the appropriate PA addresses as packets leave the host. Similarly, when virtual subnet packets enter the destination host, the PAs are rewritten with appropriate CAs,

ITMug Cloud Network 5

IP Rewrite is a NAT technology; therefore it requires a single PA IP for every virtual machine CA (in order to isolate VMs from different tenants and use overlapping IP addresses). This translates into a requirement for a large PA pool and an equally large lookup table.

Unlike the GRE approach, VSID is not included in the packets

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s