MICROSOFT NETWORK VIRTUALIZATION VILNIUS UNIVERSITY FACULTY OF MATHEMATICS AND INFORMATICS MICROSOFT NETWORK VIRTUALIZATION Student: Ștefana-Diana Budin TEACHER: TOMAS PLANKIS

summary INTRODUCTION CONCEPTS PACKET ENCAPSULATION MULTI-TENANT DEPLOYMENT EXAMPLE RESOURCES QUESTIONS?

INTRODUction In computing, network virtualization or network virtualisation is the process of combining hardware and software network resources and network functionality into a single, software-based administrative entity, a virtual network. Network virtualization involves platform virtualization, often combined with resource virtualization. Network virtualization is categorized as either external virtualization, combining many networks or parts of networks into a virtual unit, or internal virtualization, providing network-like functionality to software containers on a single network server. Server virtualization enables multiple server instances to run concurrently on a single physical host; yet server instances are isolated from each other. Each virtual machine essentially operates as if it is the only server running on the physical computer. Network virtualization provides a similar capability, in which multiple virtual networks run on the same physical network infrastructure and each virtual network operates as if it is the only virtual network running on the shared network infrastructure. 

Figure 1: Server virtualization versus network virtualization

Concepts In Hyper-V Network Virtualization (HNV), a customer or tenant is defined as the "owner" of a set of IP subnets that are deployed in an enterprise or datacenter. A customer can be a corporation or enterprise with multiple departments or business units in a private datacenter which require network isolation, or a tenant in a public data center which is hosted by a service provider. Each customer can have one or more Virtual networks in the datacenter, and each virtual network consists of one or more Virtual subnets. There are two HNV implementations which will be available in Windows Server 2016: HNVv1 and HNVv2.

HNVV1 HNVv1 is compatible with Windows Server 2012 R2 and System Center 2012 R2 Virtual Machine Manager (VMM).  SET Teaming and HNVv1 are not compatible by platform. To use HA NVGRE gateways users need to either use LBFO team or No team. Or Use Network Controller Deployed gateways with SET teamed switch.

HNVv2 A significant number of new features are included in HNVv2 which is implemented using the Azure Virtual Filtering Platform (VFP) forwarding extension in the Hyper-V Switch. HNVv2 is fully integrated with Microsoft Azure Stack which includes the new Network Controller in the Software Defined Networking (SDN) Stack.

VIRTUAL NETWORK Each virtual network consists of one or more virtual subnets. A virtual network forms an isolation boundary where the virtual machines within a virtual network can only communicate with each other.  With HNV, isolation is enforced using either NVGRE or VXLAN encapsulation to create overlay networks with the possibility of overlapping IP subnets between customers or tenants. Each virtual network has a unique Routing Domain ID (RDID) on the host. 

Virtual subnets A virtual subnet implements the Layer 3 IP subnet semantics for the virtual machines in the same virtual subnet. Each virtual subnet belongs to a single virtual network (RDID), and it is assigned a unique Virtual Subnet ID (VSID) using either the TNI or VNI key in the encapsulated packet header.  A key advantage of the virtual network and routing domain is that it allows customers to bring their own network topologies (for example, IP subnets) to the cloud. Figure 2 shows an example where the Contoso Corp has two separate networks, the R&D Net and the Sales Net. Because these networks have different routing domain IDs, they cannot interact with each other. That is, Contoso R&D Net is isolated from Contoso Sales Net even though both are owned by Contoso Corp. Contoso R&D Net contains three virtual subnets.

Figure 2: Customer networks and virtual subnets

Packet Encapsulation Each virtual network adapter in HNV is associated with two IP addresses: Customer Address (CA) The IP address assigned by the customer, based on their intranet infrastructure. This address allows the customer to exchange network traffic with the virtual machine as if it had not been moved to a public or private cloud. The CA is visible to the virtual machine and reachable by the customer. Provider Address (PA) The IP address assigned by the hosting provider or the datacenter administrators based on their physical network infrastructure. The PA appears in the packets on the network that are exchanged with the server running Hyper-V that is hosting the virtual machine. The PA is visible on the physical network, but not to the virtual machine.

The following diagram shows the conceptual relationship between virtual machine CAs and network infrastructure PAs as a result of network virtualization.

In the diagram, customer virtual machines are sending data packets in the CA space, which traverse the physical network infrastructure through their own virtual networks, or "tunnels". In the example above, the tunnels can be thought of as "envelopes" around the Contoso and Fabrikam data packets with green shipping labels (PA addresses) to be delivered from the source host on the left to the destination host on the right. The key is how the hosts determine the "shipping addresses" (PA's) corresponding to the Contoso and the Fabrikam CA's, how the "envelope" is put around the packets, and how the destination hosts can unwrap the packets and deliver to the Contoso and Fabrikam destination virtual machines correctly. This simple analogy highlighted the key aspects of network virtualization: Each virtual machine CA is mapped to a physical host PA. There can be multiple CAs associated with the same PA. Virtual machines send data packets in the CA spaces, which are put into an "envelope" with a PA source and destination pair based on the mapping. The CA-PA mappings must allow the hosts to differentiate packets for different customer virtual machines. As a result, the mechanism to virtualize the network is to virtualize the network addresses used by the virtual machines.

Network virtualization through address virtualization HNV implements overlay tenant networks using either Network Virtualization Generic Routing Encapsulation (NVGRE) or the Virtual eXtensible Local Area Network (VXLAN). VXLAN is the default. Virtual eXtensible Local Area Network (VXLAN) The Virtual eXtensible Local Area Network (VXLAN) protocol has been widely adopted in the market place, with support from vendors like Cisco, Brocade, Arista, Dell, HP and others. The VXLAN protocol uses UDP as the transport. 

This network virtualization mechanism uses the Generic Routing Encapsulation (NVGRE) as part of the tunnel header. In NVGRE, the virtual machine's packet is encapsulated inside another packet. The header of this new packet has the appropriate source and destination PA IP addresses in addition to the Virtual Subnet ID, which is stored in the Key field of the GRE header, as shown in the figure below.

MULTI-TENANT DEPLOYMENT EXAMPLE The Virtual Subnet ID allows hosts to identify the customer virtual machine for any given packet, even though the PA's and the CA's on the packets may overlap. This allows all virtual machines on the same host to share a single PA. MULTI-TENANT DEPLOYMENT EXAMPLE The following diagram shows an example deployment of two customers located in a cloud datacenter with the CA-PA relationship defined by the network policies.

RESOURCES https://docs.microsoft.com/en-us/ https://www.wikipedia.org

QUESTIONS?