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

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.

Following are the primary new features for Hyper-V Virtual Switch.

• Windows PowerShell commands for Hyper-V Virtual Switch

• Multiple Virtual NICs

• New security features for Hyper-V Virtual Switch

• Private Virtual Local Area Network (PVLAN) and Trunk Mode

• Port Mirroring

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

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.

Add-VMNetworkAdapter
Add-VMNetworkAdapterAcl
Add-VMSwitch
Add-VMSwitchExtensionPortFeature
Add-VMSwitchExtensionSwitchFeature
Connect-VMNetworkAdapter
Disable-VMSwitchExtension
Enable-VMSwitchExtension
Get-VMNetworkAdapter
Get-VMNetworkAdapterAcl
Get-VMNetworkAdapterFailoverConfiguration
Get-VMNetworkAdapterVlan
Get-VMSwitch
Get-VMSwitchExtension
Get-VMSwitchExtensionPortData
Get-VMSwitchExtensionPortFeature
Get-VMSwitchExtensionSwitchData
Get-VMSwitchExtensionSwitchFeature
Get-VMSystemSwitchExtension
Get-VMSystemSwitchExtensionPortFeature
Get-VMSystemSwitchExtensionSwitchFeature
New-VMSwitch
Remove-VMNetworkAdapter
Remove-VMNetworkAdapterAcl
Remove-VMSwitch
Remove-VMSwitchExtensionPortFeature
Remove-VMSwitchExtensionSwitchFeature
Rename-VMNetworkAdapter
Rename-VMSwitch
Set-VMNetworkAdapter
Set-VMNetworkAdapterFailoverConfiguration
Set-VMNetworkAdapterVlan
Set-VMSwitch
Set-VMSwitchExtensionPortFeature
Set-VMSwitchExtensionSwitchFeature

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.

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:

Add-VMNetworkAdapter –ManagementOS –Name Management
Add-VMNetworkAdapter –ManagementOS –Name Storage
Add-VMNetworkAdapter –ManagementOS –Name “Live Migration”

New security features for Hyper-V Virtual Switch

Hyper-V Virtual Switch includes the following new security features in Windows Server 2012.

• Port Access Control Lists (ACLs)

• MacAddressSpoofing

• RouterGuard

• DHCPGuard

• IPsec Task Offload (IpsecTO)

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:

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:

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

Add-VMNetworkAdapterAcl  -VMName MyVM –LocalMacAddress 12-34-56-78-9A-–Direction Both –Action Allow
Add-VMNetworkAdapterAcl  -VMName MyVM –LocalMacAddress FF-FF-FF-FF-FF-FF  –Direction InBound –Action Allow
Add-VMNetworkAdapterAcl  -VMName MyVM –LocalMacAddress Any  –Direction Both –Action Deny

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.

Add-VMNetworkAdapterAcl –VMName MyVM –RemoteIPAddress 192.168.0.0/16 –Direction Outbound –Action Meter

MacAddressSpoofing

MacAddressSpoofing allows you to specify whether a VM is allowed to change its source MAC address for outgoing packets.

If you have a VM for which you want to allow MacAddressSpoofing, you can enable it using the following cmdlet.

Set-VMNetworkAdapter –VMName MyVM –MacAddressSpoofing On

For all other VMs, you can block the ability to spoof MAC addresses with the following cmdlet.

Set-VMNetworkAdapter –VMName CustomerVM –MacAddressSpoofing Off

For more information, see Set-VMNetworkAdapter.

RouterGuard

RouterGuard allows you to specify whether the router advertisement and redirection messages from unauthorized VMs should be dropped.

If you have a VM for which you want to allow router advertisement and redirection messages from unauthorized VMs, you can use the following cmdlet.

Set-VMNetworkAdapter –VMName MyVM –RouterGuard Off

For all other VMs, you can block router advertisement and redirection messages from unauthorized VMs with the following cmdlet.

Set-VMNetworkAdapter –VMName CustomerVM –RouterGuard On

For more information, see Set-VMNetworkAdapter.

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.

Set-VMNetworkAdapter –VMName MyVM -IPsecOffloadMaximumSecurityAssociation 200

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

Network isolation is related to security, but unlike IPsec - which encrypts the network traffic - isolation logically segments the traffic.

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 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.

Set-VMNetworkAdapterVlan –VMName MyVM –Isolated –PrimaryVlanId 10 –SecondaryVlanId 200

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.

Set-VMNetworkAdapterVlan –VMName MyVM –Trunk –AllowedVlanIdList 1-100 –NativeVlanId 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.

Set-VMNetworkAdapter –VMName MyVM –PortMirroring Source
Set-VMNetworkAdapter –VMName MyVM2 –PortMirroring Source
Set-VMNetworkAdapter –VMName MonitorVM –PortMirroring Destination

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.

Enable-NetAdapterVmq GuestTrafficNic

For more information, see Enable-NetAdapterVmq.