Virtualized Environments and Networking
In order to offer cost-effective and efficient computing environments that can quickly accept and reconfigure to support new workloads or changes in existing workloads, companies are shifting to a virtualized data center model using private or public clouds. Network security and isolation are key areas of concern when deploying a virtualized environment where multiple customer workloads reside on shared resources and physical isolation no longer exists. In addition to network security and workload isolation concerns, customers may need to maintain current IP address models when migrating resources to a virtualized environment.
With the release of Windows Server 2012, Microsoft introduced a new Software Defined Networking (SDN) strategy to address these concerns. Through SDN in Windows Server 2012 and Windows Server 2012 R2, Microsoft enables dynamic configuration of virtual networks on top of the physical network, and the ability to move virtual networks across the physical network in a quick and efficient manner. Another area that SDN affects is network traffic flow control. Virtualized workload data may require bandwidth guarantees and caps that change over time, or require specialized security filters. Using the SDN strategy, network policies are created and changed dynamically as workload requirements change. The SDN strategy resulted in the introduction of Hyper-V Virtual Networking (HVN) and the Hyper-V Extensible Switch in Windows Server 2012, and several important enhancements in Windows Server 2012 R2.
Hyper-V Virtual Networking
Hyper-V Virtual Networking (HNV) provides the ability to overlay logical network address spaces, or customer addresses (CA), on top of physical IP address spaces, or provider addresses (PA), to support secure and isolated multi-tenancy environments. Using HNV, you can implement multiple secure and isolated CAs without having to reconfigure the underlying PA infrastructure. Because CA spaces are logical and isolated, multiple customers can use the same subnet address ranges for their workloads on a single physical address space, without experiencing any address conflicts.
Hyper-V leverages Network Virtualization for Generic Routing Encapsulation (NVGRE) as the mechanism to virtualize IP addresses to succesfully route workload packets. Figure 1 shows the GRE network packet format.
Figure 1: NVGRE Packet Format
A virtual machine (workload) packet is encapsulated inside another packet, which uses the source and destination IP addresses in addition to a virtual subnet ID to route the customer packet. The virtual subnet ID allows host virtual switches to identify which virtual machine a packet is destined for even though the CAs might be the same. This is what allows all the virtual machines on a single host to share a single PA space.
Hyper-V Extensible Switch
The Hyper-V Extensible Switch is a layer-2 virtual network switch that enables virtual machines to connect to a physical network infrastructure. In order to meet the demanding security requirements of enterprise and service provider infrastructures, Microsoft made the switch extensible and programmatically manageable using published Windows APIs.
The extensibility of the switch allows third-party vendors, enterprises, and service providers to meet unique security requirements and provide additional features. Multiple third-party vendors have already released Hyper-V Extensible Switch extensions including Cisco, NEC, 5Nine, and InMon. The extensions range from security enhancements, to virtual firewalls, traffic flow, and network monitoring functionality.
Supported Extension Types
The Hyper-V Extensible Switch allows the development of three types of extensions, namely Capturing extensions, Filtering extensions, and Forwarding extensions.
All three extension types are developed as NDIS filter drivers and install as modified filter drivers. There is no limit to the number of each type of extension that can be installed on a Hyper-V Extensible Switch. Each extension installs in a layered approach by type. By default, the last extension installed in the layer will be the first to handle a packet flowing through the switch, but it is possible to reorder the extensions to change the filtering order. The first extension in the layer inspects the packet and then hands the packet off to the next extension in the layer.
Capturing Extensions
A Capturing extension allows the capturing and monitoring of packet traffic that is flowing through a Hyper-V virtual switch. A Capturing extension cannot modify, drop, or change the delivery of packets to an extensible switch port. This makes a Capturing extension ideal for network monitors that inspect packet traffic and status.
A Capturing extension can monitor packets across the inbound (ingress) and outbound (egress) data path, but it can not modify the data within the packets nor add port destinations to the out-of-band data of the packet. It is possible for a Capturing extension to create packets specifically for reporting traffic conditions to monitoring applications.
Filtering Extensions
A Filtering extension has the same capabilities as a Capturing extension to monitor and inspect packets flowing through the Hyper-V Extensible Switch. However, a Filtering extension also has the ability to drop packets or exclude packet delivery to an extensible switch port. In addition, a Filtering extension can originate or duplicate packets and inject them into the extensible switch data path.
Filtering extensions have slightly different capabilities depending on the data path. On the inbound packet data path (ingress), a Filtering extension can only apply filtering rules on the source port of the packet and the network adapter connection. On the outbound packet data path (egress), a Filtering extension can apply filter rules on the source and destination port of the packet.
Filter rules can include controlling the flow of data based on source or destination port, blocking the delivery of a packet to one or more extensible switch ports, postponing the forwarding of packets on the outbound path, and the ability to clone a packet and modify the data and destination port.
Forwarding Extensions
A Forwarding extension has the same capabilities as a Filtering extension. Forwarding extensions perform core packet forwarding and filtering for the Hyper-V Extensible Switch. They accomplish this by determining the destination port for the packet, and filtering packets by enforcing port policies like security or profile policies.
Forwarding extensions can apply filtering rules on the source or destination ports regardless of the data flow direction. Forwarding rules can also inject new, modified, or cloned packets on the inbound data path, but can only modify cloned packets on the outbound data path or exclude the delivery to a destination port. A Forwarding extension can only exclude packet delivery on the outbound data path and can only add or modify destination ports for the packet on the inbound data path.
Windows Server 2012 R2 Enhancements to the Hyper-V Extensible Switch
When the Hyper-V Extensible Switch released with Windows Server 2012, HVN was implemented as a network filter outside of the virtual switch. This design approach only allowed the virtual switch extensions to see the CA space because any NVGRE encapsulation or decapsulation of PA space occurred outside the switch. This design prevented switch extensions from monitoring or modify packets based on the PA space.
To address this limitation, two changes enhanced the Hyper-V Extensible Switch design in Windows Server 2012 R2.
-
The HVN implementation moved into the Hyper-V Extensible Switch.
-
The Hyper-V Extensible Switch gained the ability to forward a packet based on packet type (hybrid forwarding).
Moving the HVN implementation into the Hyper-V Extensible Switch allows any installed extension to see both the CA and PA spaces. Implementing hybrid forwarding allows the packet to be forwarded by different modules based on the packet type. For example, traffic encapsulated with NVGRE is handled by the HVN module, and non-NVGRE traffic bypasses the HVN module and is handled by the forwarding extension. The forwarding extension can apply additional policies to a packet even if the HVN module forwarded it.
Packet Flow Details
Figure 2 shows the ingress and egress traffic flow for packets using the Windows Server 2012 R2 implementation of the Hyper-V Extensible Switch.
Figure 2: Hyper-V Extensible Switch Ingress and Egress Traffic Flow
Two separate packet flow scenarios must be considered to understand the Hyper-V Extensible Switch:
-
A packet originates from an external source
-
A packet originates from a Hyper-V host or virtual machine on a Hyper-V host
In the first case, when a packet originates from an external source, if the packet does not leverage HVN, then there is no need to perform encapsulation and decapsulation, since NVGRE is not used. The packet flows through all installed capture and filtering extensions, then directly to the forwarding extension, bypassing HVN. As the packet flows out the egress path, it goes back through any forwarding, filtering and capture extensions.
If the packet originates from an external source and leverages HVN, then the packet will have been encapsulated using NVGRE at the source. As it flows into the ingress path at the destination, it is decapsulated by the HVN module and mapped to the CA space. The packet then flows through the forwarding, filtering and capture extensions as it takes the egress path.
In the second case, if a packet originates from a Hyper-V host or a virtual machine on a Hyper-V host and it does not leverage HVN, it will have a PA and not be encapsulated using NVGRE. The packet passes through capture and filtering extensions, then goes straight to the forwarding extension. Once it passes through the forwarding extension, the packet is processed as egress traffic through the filtering and capture extensions.
If the packet originates from a Hyper-V host or a virtual machine on a Hyper-V host and it leverages HVN, the packet will have a CA. As it flows into the ingress path, it goes through the capture and filtering extensions before the HVN module processes the packet. The HVN module performs encapsulation and changes the addresses to the PA. The packet then flows up the egress path through all the extensions.
Conclusion
With Windows Server 2012 R2, Microsoft enhanced Hyper-V Virtual Networking and the Hyper-V Extensible Switch making it an even more robust and trusted platform for the deployment of multi-tenant private and public cloud environments. The Hyper-V Extensible Switch allows third-party vendors to develop extensions that provide specialized functionality without the need to deploy a virtual machine or physical device into the network architecture. Examples of extensions that leverage the Hyper-V Extensible Switch are the Cisco Nexus 1000V and 5Nine Cloud Security for Hyper-V. Leveraging the Hyper-V Extensible Switch, these extensions can process packets and provide capabilities that are specialized without installing agents in any virtual machines, regardless of the virtual machine guest operating system, and without requiring complex physical network reconfiguration. This reduction in network complexity, better routing performance, and more options for capturing, filtering, and forwarding virtualized workload data packets improve the network isolation and security required in the virtualized data center.
