In this article

What's New in Hyper-V Virtual Switch in Windows Server 2012

08/31/2016

11 minutes to read

In this article

Applies To: Windows Server 2012 R2, Windows Server 2012

In Windows Server® 2012, Hyper-V Virtual Switch includes new features for manageability, security, isolation, visibility, and scalability to provide more effective Hyper-V deployment in your on-site or private, hybrid, or public cloud environments.

Windows PowerShell commands for Hyper-V Virtual Switch

You can now use Windows PowerShell commands, run manually or in scripts, to configure Hyper-V Virtual Switch and related features.

PowerShell syntax consists primarily of <verb>-<noun> pairs. For example, the following command displays all of the Hyper-V Virtual Switches that are configured on your server.

Get-VMSwitch

Windows PowerShell nouns that are provided for the Hyper-V Virtual Switch are:

VMNetworkAdapter
VMNetworkAdapterAcl
VMNetworkAdapterVlan
VMSwitch

A VMNetworkAdapter includes the following elements:

The virtual network interface card (NIC) in the VM

Hyper-V Virtual Switch port

VMNetworkAdapter is the primary noun that you can use to manage various security features, Quality of Service (QoS), port mirroring, and other items. For more information on these features, type the following into Windows PowerShell, and then press ENTER:

Get-Help Set-VMNetworkAdapter

To view all of the Windows PowerShell verbs for VMNetworkAdapter, type the following command into Windows PowerShell, and then press ENTER:

Get-Help *-VMNetworkAdapter

To view the current state of a VMNetworkAdapter, type the following command into Windows PowerShell, and then press ENTER:

Get-VMNetworkAdapter –VMName MyVM | format-list *

Following are the Windows PowerShell commands that you can use to configure the Virtual Switch and virtual network adapters. A full command reference for these and other Hyper-V Windows PowerShell cmdlets, including syntax and examples, is available at Hyper-V Cmdlets in Windows PowerShell.

When using Windows PowerShell commands on physical NICs, use the NetAdapter family of cmdlets; and when using Windows PowerShell commands on virtual NICs, use the VMNetworkAdapter family of cmdlets. If you only have a single NIC or a team of NICs bound to the Hyper-V Virtual Switch, you can use multiple parent virtual NICs as well.

Multiple Virtual NICs

In previous versions of Hyper-V, only one parent virtual NIC was supported, however in Windows Server 2012 Hyper-V, multiple NICs are supported. In addition, you can share the physical NIC that is bound to the Hyper-V Switch with the management operating system.

Tip

To enable this functionality, open Hyper-V Manager. In the Actions pane, select Virtual Switch Manager. In Virtual Switch Manager, select a switch. In the details pane for the switch, which is illustrated below, select Allow management operating system to share this network adapter.

You can create multiple parent virtual NICS that you use for live migration, storage, and management; and you can assign each virtual NIC to a different virtual Local Area Network (VLAN). You can also create different Quality of Service (QoS) polices for each virtual NIC.

A multiple NIC configuration is illustrated below:

To create the virtual NICS for the management operating system, type the following commands at the Windows PowerShell prompt, and then press ENTER:

New security features for Hyper-V Virtual Switch

Most of these features provide you with the ability to specify the types of packets that are allowed or blocked when sent to or from the virtual machines that are connected to the virtual switch. The following sections provide additional details.

Port Access Control Lists (ACLs)

A port ACL is a rule that you can apply to a Hyper-V switch port. The rule specifies whether a packet is allowed or denied on the way into or out of the VM. ACLs have three elements with the following structure: Local or Remote Address | Direction | Action.

You can specify either a local address or a remote address in Local or Remote Address, but you cannot specify both. The value that you supply for Local or Remote Address can be an IPv4 address, an IPv6 address, or a media access control (MAC) address. Optionally you can use an IP address range if you provide the range prefix.

You can configure multiple port ACLs for a Hyper-V switch port. During operations, the port ACL whose rules match the incoming or outgoing packet is used to determine whether the packet is allowed or denied.

For example, to configure the virtual NIC attached to a port to always use either a specific MAC address or a broadcast address, you can create rules that are similar to the following:

Local or Remote Address

Direction

Action

12-34-56-78-9A-BC

Inbound

Allow

12-34-56-78-9A-BC

Outbound

Allow

FF-FF-FF-FF-FF-FF

Inbound

Allow

Any

Inbound

Deny

Any

Outbound

Deny

In this example, Any is a wildcard. Note that ACLs are evaluated on the longest prefix that is matched. Therefore the MAC address 12-34-56-78-9A-BC with the Allow rule takes precedence over the wildcard rule that has an address of Any.

Bi-directional port ACLs

In many cases, you will want to apply the same permissions for both Inbound and Outbound traffic in the same port ACLs. For example, you want to allow both Inbound and Outbound traffic; or you want to deny both Inbound and Outbound traffic.

Because of this, there are bi-directional port ACLs. These ACL entries save some administrative time by allowing you to configure Inbound and Outbound permissions with one port ACL entry. You can accomplish the same effect as the first example by using bi-directional port ACLs in the following way:

Local or Remote Address

Direction

Action

12-34-56-78-9A-BC

Both

Allow

FF-FF-FF-FF-FF-FF

Inbound

Allow

Any

Both

Deny

The following commands demonstrate how you can create this configuration by using Windows PowerShell:

The above examples focus on ACLs that are defined by using the Local Address. You can also define ACLs by using the Remote Address. This is useful for blocking a particular address by using a remote address with a deny action.

Meter port ACLs

Meter port ACLs allow you to measure how much traffic is sent to or from the virtual NIC to a specified address range.

For example, the following meter port ACL measures the traffic that is sent from the VM named MyVM to the IPv4 subnet 192.168.0.0/16.

DHCPGuard

DHCPGuard allows you to specify whether DHCP server messages coming from a VM should be dropped. For VMs that are running an authorized instance of the DHCP server role, you can turn DHCPGuard off by using the following cmdlet:

Set-VMNetworkAdapter –VMName MyDhcpServer1 –DhcpGuard Off

For all other VMs that are not authorized DHCP servers, you can prevent them from becoming a rogue DHCP server by turning DHCPGuard on, using the following cmdlet.

Set-VMNetworkAdapter –VMName CustomerVM –DhcpGuard On

IPsec Task Offload (IpsecTO)

Many encryption algorithms are processor-intensive, which can slow the performance of VMs. Hyper-V Virtual Switch now provides VMs with the ability to use IPsecTO, which allows the VM to offload encryption processes to the NIC. Offloading the per-packet encryption operations from the VM to the NIC results in substantial CPU savings.

IPsec includes a Security Association (SA) with which it performs encryption, and when you enable IPsecTO, the VM offloads the SA to the NIC for processing. IPsecTO-capable NICs have a limited number of SAs that can be offloaded, so you can use Windows PowerShell to designate the number of SAs that the VM can offload to the NIC. To manage the number of SAs that can be offloaded by a VM you can use the following cmdlet.

This cmdlet limits the number of SAs that can be offloaded by the VM named MyVM to 200. After the limit is reached, the Windows Networking stack in the VM intelligently manages the SAs so that the more active SAs are offloaded, while less active SAs are uploaded and performed by the VM.

Requirements for using IPsecTO

Following are the requirements for using IPsecTO.

Only VMs running Windows Server® 2008 R2 and Windows Server 2012 are supported, because the VM’s network stack must support IPsecTO.

The physical NIC must also support IPsecTO.

Private Virtual Local Area Network (PVLAN) and Trunk Mode

VLANs, however, suffer scalability issues. A VLAN ID is a 12-bit number, and VLANs are in the range 1-4095. In a multitenant data center, if you want to isolate each tenant by using a VLAN, configuration is complex and difficult. These scalability issues of VLANs are solved when you deploy Hyper-V Network Virtualization, where tenants each have multiple virtual subnets. However, a simple solution when each tenant only has a single VM is to use PVLAN.

PVLAN addresses some of the scalability issues of VLANs. PVLAN is a switch port property. With PVLAN there are two VLAN IDs, a primary VLAN ID and a secondary VLAN ID. A PVLAN may be in one of three modes.

PVLAN Mode

Description

Isolated

Communicates only with Promiscuous ports in the PVLAN

Promiscuous

Communicates with all ports in the PVLAN

Community

Communicates with ports in the same community and any promiscuous ports in the PVLAN

PVLAN can be used to create an environment where VMs may only interact with the Internet and not have visibility into other VMs’ network traffic. To accomplish this put all VMs (actually their Hyper-V switch ports) into the same PVLAN in isolated mode. Therefore, using only two VLAN IDs, primary and secondary, all VMs are isolated from each other. The following PowerShell script puts a VM’s switch port into PVLAN isolated mode.

When using any Hyper-V VLAN feature, the physical switches must also be properly configured with the appropriate VLAN IDs.

Trunk mode

In addition to PVLAN, Hyper-V Virtual Switch also provides support for VLAN trunk mode. Trunk mode provides network services or network appliances on a VM with the ability to see traffic from multiple VLANs.

In trunk mode, a switch port receives traffic from all VLANs that you configure in an allowed VLAN list. You can also configure a switch port that is connected to a VM - but is not bound to the underlying NIC - for trunk mode.

In the following example cmdlet, MyVM can send or receive traffic on any VLAN in the allowed list. If there is no VLAN specified in the packet, the packet is treated as if it is from VLAN 10.

Port Mirroring

With Port Mirroring, traffic sent to or from a Hyper-V Virtual Switch port is copied and sent to a mirror port. There are a range of applications for port mirroring - an entire ecosystem of network visibility companies exist that have products designed to consume port mirror data for performance management, security analysis, and network diagnostics. With Hyper-V Virtual Switch port mirroring, you can select the switch ports that are monitored as well as the switch port that receives copies of all the traffic.

The following examples configure port mirroring so that all traffic that is sent and received by both MyVM and MyVM2 is also sent to the VM named MonitorVM.

Receive Side Scaling (RSS) and Dynamic Virtual Machine Queue (dVMQ)

In networking it is important to resolve circumstances where network traffic is blocked or slowed down, thereby causing latency.

For native traffic, Receive Side Scaling (RSS) processes incoming network traffic so that it isn’t slowed down by a single CPU. RSS processes the IP source and destination fields and TCP source and destination ports to spread the receive traffic across multiple CPU cores.

For receive network traffic coming externally from the server and into the Hyper-V Virtual Switch, Dynamic Virtual Machine Queue (dVMQ) performs a function similar to RSS. With dVMQ, the destination MAC address is hashed to put the traffic destined for a virtual NIC into a specific queue. The interrupts to the CPU cores are also distributed to avoid being slowed by a single CPU core. If your VMs on a Hyper-V Virtual Switch receive a lot of external network traffic, it’s a good idea to use dVMQ.

dVMQ also includes dynamic load balancing. Previously, the MAC hashing was done statically, and it was difficult to manage dVMQ. Management of dVMQ is now simple – it is enabled by default, and no other management steps are required.

If for some reason you have disabled dVMQ, you can enable it again by using the following cmdlet. The NIC in this example is a physical NIC that is bound to the virtual switch, and it is named GuestTrafficNic.