Windows NIC Teaming using PowerShell (Part 7)

If you would like to read the other parts in this article series please go to:

In the previous two articles of this series we began describing how to use Windows PowerShell to implement Windows NIC Teaming on a virtual machine running on a Hyper-V host. We also examined what happened when one member of the team failed. This present article examines some additional considerations when implementing Windows NIC Teaming in a virtual machine.

Quick Review

As a quick review, our test environment has a virtual machine named SRV35 running on a Hyper-V host. Both the host and guest operating systems are Windows Server 2012 R2.

The host has two physical network adapters that provide Internet connectivity. The host also has four Hyper-V virtual switches configured, two of which are of the external type while the other two are internal and private.

The virtual machine has four virtual network adapters installed, each of which is assigned to a different virtual switch on the host.

The following table summarizes the network configurations of the Hyper-V host and virtual machine:

Name of   virtual network adapter

Virtual   switch assigned to adapter

Type of   virtual switch

Ethernet

vSwitch-1

External

Ethernet 2

vSwitch-PRI

Private

Ethernet 3

vSwitch-INT

Internal

Ethernet 4

vSwitch-2

External

 Table 1

Considerations when adding team members

Recall that we previously used the New-NetLbfoTeam to create a new NIC team in the virtual machine. This team has two members (Ethernet and Ethernet 4) and each of these members is assigned to a different external virtual switch on the host.

Let’s start by using the Get-NetLbfoTeam and Get-NetLbfoTeamMember cmdlets to verify that both team members are active:

PS C:\> Get-NetLbfoTeam | Get-NetLbfoTeamMember

Name                    : Ethernet 4
InterfaceDescription    : Microsoft Hyper-V Network Adapter #4
Team                    : VMTestTeam
AdministrativeMode      : Active
OperationalStatus       : Active
TransmitLinkSpeed(Gbps) : 10
ReceiveLinkSpeed(Gbps)  : 10
FailureReason           : NoFailure

Name                    : Ethernet
InterfaceDescription    : Microsoft Hyper-V Network Adapter
Team                    : VMTestTeam
AdministrativeMode      : Active
OperationalStatus       : Active
TransmitLinkSpeed(Gbps) : 10
ReceiveLinkSpeed(Gbps)  : 10
FailureReason           : NoFailure

Let’s now try adding a third member to our team. We’ll use the virtual network adapter named “Ethernet 2” for this purpose, and we’ll use the Add-NetLbfoTeamMember cmdlet to try to add this virtual network adapter to our team in the virtual machine:

PS C:\> Add-NetLbfoTeamMember -Name “Ethernet 2” -Team VMTestTeam -Confirm:$false

Name                    : Ethernet 2
InterfaceDescription    : Microsoft Hyper-V Network Adapter #2
Team                    : VMTestTeam
AdministrativeMode      : Active
OperationalStatus       : Failed
TransmitLinkSpeed(Mbps) : 0
ReceiveLinkSpeed(Mbps)  : 0
FailureReason           : VirtualSwitchLacksExternalConnectivity

This didn’t work as expected as the command output above indicates that the operational status of the new team member is Failed with a reason of VirtualSwitchLacksExternalConnectivity.

Let’s use Get-NetLbfoTeam to get the current info about the team:

PS C:\> Get-NetLbfoTeam

Name                   : VMTestTeam
Members                : {Ethernet 2, Ethernet 4, Ethernet}
TeamNics               : VMTestTeam
TeamingMode            : SwitchIndependent
LoadBalancingAlgorithm : TransportPorts
Status                 : Degraded

Our team now has three members (Ethernet 2, Ethernet 4, and Ethernet) but it’s status shows as Degraded. What’s going on?

Let’s open the NIC Teaming GUI from the command prompt as follows:

PS C:\> lbfoadmin

Figure 1 shows what we can see in the GUI for our team. We can see that the failure reason is expressed a little more clearly in the GUI as “The virtual switch lacks external connectivity.”

Image
Figure 1: Adding the virtual network adapter to the team failed.

This is the first important consideration regarding implementing NIC teaming inside a virtual machine:

Virtual network adapters that are added as team members must be connected to External type virtual networks; they cannot be connected to Internal or Private type virtual networks.

Now let’s remove the virtual network adapter we just added to the team. We can use the Remove-NetLbfoTeamMember to do this as follows:

PS C:\> Remove-NetLbfoTeamMember -Name “Ethernet 2” -Team VMTestTeam -Confirm:$false

Now let’s use Get-NetLbfoTeam to get the status of the team:

PS C:\> Get-NetLbfoTeam

Name                   : VMTestTeam
Members                : {Ethernet 4, Ethernet}
TeamNics               : VMTestTeam
TeamingMode            : SwitchIndependent
LoadBalancingAlgorithm : TransportPorts
Status                 : Up

The team is working properly now using its original two members. The NIC Teaming GUI confirms this as shown in Figure 2 below.

Image
Figure 2: The team is working properly again.

Let’s try changing the teaming mode of our team from Switch Independent teaming mode to Static teaming mode. We can use the Set-NetLbfoTeam for this purpose as follows:

PS C:\> Set-NetLbfoTeam -Name VMTestTeam -TeamingMode Static

Set-NetLbfoTeam : ‘SwitchIndependent’ is the only TeamingMode value supported in a Virtual Machine
At line:1 char:1
+ Set-NetLbfoTeam -Name VMTestTeam -TeamingMode Static
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (MSFT_NetLbfoTea…2F94693B1C8A
   }”):root/StandardCimv2/MSFT_NetLbfoTeam) [Set-NetLbfoTeam], CimException
    + FullyQualifiedErrorId : MiClientApiError_InvalidParameter,Set-NetLbfoTeam

The PowerShell command has thrown an exception and provides the following reason: ‘SwitchIndependent’ is the only TeamingMode value supported in a Virtual Machine.

Let’s try something else then. How about if we change the load balancing mode from Transport Ports (a form of Address Hash load balancing) to Hyper-V Port? Let’s try doing this and see what happens:

PS C:\> Set-NetLbfoTeam -Name VMTestTeam -LoadBalancingAlgorithm HyperVPort

Set-NetLbfoTeam : The only valid LoadBalancingAlgorithms in a Virtual Machine are ‘TransportPorts’, ‘IPAddresses’, and ‘MacAddresses’
At line:1 char:1
+ Set-NetLbfoTeam -Name VMTestTeam -LoadBalancingAlgorithm HyperVPort
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidArgument: (MSFT_NetLbfoTea…2F94693B1C8A
   }”):root/StandardCimv2/MSFT_NetLbfoTeam) [Set-NetLbfoTeam], CimException
    + FullyQualifiedErrorId : MiClientApiError_InvalidParameter,Set-NetLbfoTeam

Once again we see an exception, this time with a failure reason of: The only valid LoadBalancingAlgorithms in a Virtual Machine are ‘TransportPorts’, ‘IPAddresses’, and ‘MacAddresses’

The above examples indicate two other important considerations when implementing NIC teaming inside a virtual machine:

Switch Independent is the only supported teaming mode when you implement NIC teaming in a virtual machine. You cannot use Static Teaming or LACP as a teaming mode for teamed virtual network adapters.

Address Hash is the only supported load balancing mode when you implement NIC teaming in a virtual machine. You cannot use Hyper-V Port as a load balancing mode for teamed virtual network adapters.

In addition, we can see from the second example above that Address Hash load balancing can be configured using PowerShell to utilize one of three different kinds of hashing methods:

  • TCP Ports  Uses the source and destination TCP ports and also the source and destination IP addresses as inputs for the hashing function. Note that this is the default hashing method when Address Hash is selected in the NIC Teaming GUI as the load balancing mode for the team.
  • IP Addresses  Uses only the source and destination IP addresses as inputs for the hashing function.
  • MAC Addresses  Uses only the source and destination MAC addresses as inputs for the hashing function.

In some scenarios the particular form of traffic being routed by the team may not support TCP Ports as a hashing method. An example of this would be IPsec traffic. In this case, the hashing method falls back to the IP Address hash method. And if the traffic is not even IP traffic, the hashing method falls back to the MAC Address hash method.

Conclusion

The next and final article in this series will describe some additional considerations when implementing NIC teaming in both physical and virtual environments.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

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

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top