Network Bindings in Hyper-V

So far, this series has spent most of its time focused on the methods that systems use to decide where traffic should go and how it should get there. A logical next step is to discuss how bindings work. I wrote about binding order earlier. What this article will do is bring the concepts of that topic inline with the aims of this series along with an explanation of the machinations of binding.

• Part 1 – Mapping the OSI Model
• Part 2 – VLANs
• Part 3 – IP Routing
• Part 4 – Link Aggregation and Teaming
• Part 5 – DNS
• Part 6 – Ports, Sockets, and Applications
• Part 7 – Bindings
• Part 8 – Load-Balancing Algorithms

Network Binding Basics

The concept of binding is fairly simple. It determines what capabilities will be available to a given adapter. You can choose what will be bound to an adapter and their order of precedence.

Let’s start by looking at the bindings for a typical physical network adapter:

Each line item represents a technology available for use by this adapter. They are organized, beginning with clients, then services, and finally protocols. The adapter is prevented from using any unchecked items. For instance, many organizations don’t need the advanced features of IPv6 and will unbind it to simplify management.

Binding Order

Binding order is not of great importance in Hyper-V, although a lot of people spend a great deal of time trying to perfect it for their systems. I recommend that you ignore binding order for your Hyper-V host. Read the previously referenced article for more information about why. But, we can spend a little bit of time taking a closer look at what happens.

First, you get here by starting on the Network Connections screen. Press ALT to make the menu bar appear. Click Advanced, then Advanced Settings:

This will reward you with the following screen:

In the top area, you can change the order that Windows chooses to access adapters when it doesn’t have any other hints. In my observations, this doesn’t work reliably, which is one of the reasons I recommend you not use it for Hyper-V.

Reasons People Try to Use Binding Order for Hyper-V

The most prominent reason people attempt to manipulate the binding order in Hyper-V is when the host is joined to a cluster. This is because a cluster requires multiple adapters for the management operating system, resulting in a multi-homed system. When such a system is not configured properly, it may choose the wrong adapter for some communications, resulting in a wide variety of problems.

The other reason is a misunderstanding of the Hyper-V switch. All Hyper-V installations, cluster or not, require a management adapter for the operating system and the virtual switch for the guests. Unfortunately, too many people take this to mean that the Hyper-V switch needs some sort of network presence of its own the same way that a regular adapter does. So, they try to find ways to modify the bindings and binding order between the management adapter and the virtual switch. This should never be done.

Bindings and the Hyper-V Virtual Switch

Here’s a picture of what an adapter properly bound to the Hyper-V virtual switch looks like:

The Broadcom bit is just there because it’s a Broadcom card and I have the entire Broadcom package installed. Other than that, the only thing bound to this adapter is the Hyper-V Extensible Switch. That’s exactly as it should be. Attempting to bind anything else should be blocked by the system, but if you manage to do it, you’ll probably break something.

Beyond that, network bindings have no real purpose for Hyper-V. Adapters used for the management operating system are as dependent upon bindings as any other adapter in Windows. The same goes for the virtual adapters inside virtual machines. Configure them as you would any adapter in the respective operating systems.

The Multiplexor

Right beneath the Hyper-V virtual switch in the above screenshot, you can see the Microsoft Network Adapter Multiplexor Protocol. This is the magical component that makes native adapter teaming work in Windows Server. As with adapters bound to the Hyper-V switch, adapters bound to the multiplexor must be bound to nothing else.

What it All Means

To risk oversimplification, all these components are just software. Most of them act as intermediaries between the bound adapter and anything else that wants to use it. In almost all cases, that “anything else” will be the operating system. Most other software has no real concept of network adapters. They request communications of some sort and the operating system does most of the work. This is especially true when it comes to teaming.

One exception is the Hyper-V virtual switch. Hyper-V is well aware of this software component. It is through this particular binding that Hyper-V is able to control how traffic flows in and out of all connected virtual adapters. The fact that nothing else is bound is why the management operating system has no visibility into anything that happens on the Hyper-V virtual switch. Configuring firewalls and other such OS level tools will have absolutely no effect on or access to traffic on the Hyper-V switch unless they are specifically designed as extensions to the virtual switch.

What’s Next

At this point, we’ve covered the major aspects of generic networking in relation to Hyper-V. Now it’s time to start moving into technologies that are more Hyper-V specific.