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.

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:

Protocol BindingsEach 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:

Network ConnectionsThis will reward you with the following screen:

Adapter BindingsIn 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:

Virtual Switch Adapter BindingsThe 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.


Altaro Hyper-V Backup
Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

6 thoughts on "Network Bindings in Hyper-V"

  • Roland says:

    Awesome! Very well done. Exactly what I have been learning and what I wanted to learn more about that makes networking fun. Your article cleared a lot of stuff for me and basically collected stuff that I also learned from different sources. Thank you!

  • Tim says:

    Could you post what a ‘properly configured’ ‘Hyper-V Virtual Ethernet Adapter’ looks like from the host configuration? Also, you showed two adapter bindings above, was one the physical card at the host and the 2nd a ‘virtual’ nic within the hyper-v guest or was the 2nd binding of a 2nd physical card on the host? (sorry if I missed that in your descriptions)…. Very informative, thanks

    • Eric Siron says:

      The first image is for any plain, ordinary adapter included for reference. In fact, if you have a virtual adapter it should look just like that except that the “Connect using” field will show “Hyper-V Virtual Ethernet Adapter”. Some of the binding options might be a little bit different as well. What’s important is that you can bind normal services and protocols to a Hyper-V virtual adapter, like IPv4 and IPv6.
      The second image is to show what a physical adapter looks like once you’ve bound the switch to it. It’s mostly there so that you know that it should not have other services and protocols bound.
      Does that help?

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published.

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.