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. 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:
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. 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.
No comments: