Hyper-V Network Virtualization Packet Forwarding Improvements in Windows Server 2012 R2

Initial release of Hyper-V Network Virtualization (HNV) was an add-on to the Hyper-V Extensible Switch, resulting in an interesting mixture of bridging and routing. In Windows Server 2012 R2 the two components became tightly integrated, resulting in a pure layer-3 solution.

This blog post describes HNV packet forwarding in Windows Server 2012 R2. HNV behavior in Windows Server 2012 is described in another blog post.

HNV Architecture

In Windows Server 2012 R2, Hyper-V Network Virtualization became an integral part of Hyper-V Extensible Switch. It intercepts all packets traversing the switch and thus behaves exactly like a virtual switch forwarding extension while still allowing another forwarding extension (Cisco Nexus 1000V or NEC PF1000) to work within the same virtual switch.

Hyper-V Network Virtualization module effectively transforms the Hyper-V layer-2 virtual switch into a pure layer-3 switch.

Control plane setup

A pure layer-3 switch could work without MAC reachability information (that’s how early versions of Amazon VPC behaved), but Microsoft decided to retain the semblance of layer-2 networks and IP subnets. The Hyper-V Network Virtualization forwarding module thus still requires IP routing table, ARP table, and remote VM reachability information (mapping of VM IP and MAC addresses into transport network IP addresses).

The PowerShell scripts used to configure the HNV haven’t changed. IP routing table is installed in the Hyper-V hosts with the New-NetVirtualizationCustomerRoute PowerShell cmdlet. Mappings of VM IP and VM MAC addresses into transport IP addresses are created with the New-NetVirtualizationLookupRecord cmdlet.

ARP processing

Hyper-V Network Virtualization module is an ARP proxy: it replies to all broadcast ARP requests and multicast ND request assuming it has the NetVirtualizationLookupRecord for the destination IP address.

ARP requests for unknown IPv4 destinations and ND requests for unknown IPv6 destinations are flooded if the virtual network contains layer-2-only NetVirtualizationLookupRecord entries (used to implement dynamic IP addresses).

Unicast ARP/ND requests are forwarded to the destination VM to support IPv6 Network Unreachability Detection (NUD) functionality.

Packet forwarding

Hyper-V Network Virtualization module intercepts all packets received by the Hyper-V extensible switch and drops all non-IP/ARP packets. ARP/ND packets are intercepted (see above), and the forwarding of IP datagrams relies solely on the destination IP address:

  • Routing table lookup is performed to find the next-hop customer IP address. Every HNV module has full routing table of the tenant virtual network – next-hop customer IP address is the destination IP address for all destinations within the virtual network;
  • A lookup in NetVirtualizationLookupRecord table transforms next-hop customer IP address into transport IP address;
  • Destination MAC address in the forwarded packet is rewritten using the value from the NetVirtualizationLookupRecord (implementing destination MAC rewrite on inter-subnet forwarding).

When the destination transport IP address equals the local IP address (destination customer IP address resides within the local host), HNV sends the packet back to the Hyper-V Extensible Switch, which delivers the packet to the destination VM.

Extra lookup steps within the transport network are performed for non-local destinations:

  • Routing table lookup in the global IP routing table transforms transport destination IP address into transport next-hop IP address;
  • ARP/ND table lookup transforms transport next-hop IP address into transport MAC address.

HNV has full support and feature parity for IPv4 and IPv6. Whenever this blog post mentions IP, the behavior described applies equally well to IPv4 and IPv6.

Multicast and broadcast IP traffic is flooded. Flooding mechanism uses IP multicast in the transport network if there’s a NetVirtualizationLookupRecord mapping destination multicast/broadcast customer IP address into a transport multicast IP address, and source node packet replication in all other cases.

More information

Overlay Virtual Networking webinar describes architectures from numerous vendors, including Cisco, VMware, Microsoft, IBM, and Midokura.

1 comments:

  1. HNV is still confusing. What if a VM is using its own gateway. Will the packets be forwarded to that gateway or it still goes to PA's gateway?

    Thank You,
    Alex
Add comment
Sidebar