Windows 2012/2016 Networking - VLAN + Team+ Hyper-V vSwitch

1. Как создавать Team VLAN интерфейсы в Windows 2012/2016 (т.н VLAN Mode):
802.1q парсится на уровне Team-интерфейса (метод не поддерживается для Hyper-V vSwitch):

https://community.mellanox.com/docs/DOC-1845


2. Team Interfaces

There are different ways of interfacing with the team:

• Default mode: all traffic from all VLANs is passed through the team
• VLAN mode: Any traffic that matches a VLAN ID/tag is passed through.  Everything else is dropped.

Inbound traffic passes through to one team interface at once.

The only supported configuration for Hyper-V is shown above: Default mode passing through all traffic t the Hyper-V Switch.  Do all the VLAN tagging and filtering on the Hyper-V Switch.  You cannot mix other interfaces with this team – the team must be dedicated to the Hyper-V Switch.  REPEAT: This is the only supported configuration for Hyper-V.

A new team has one team interface by default. 

Any team interfaces created after the initial team creation must be VLAN mode team interfaces (bound to a VLAN ID).  You can delete these team interfaces.

Get-NetAdapter: Get the properties of a team interface

Rename-NetAdapter: rename a team interface

Team Members

• Any physical ETHERNET adapter with a Windows Logo (for stability reasons and promiscuous mode for VLAN trunking) can be a team member.
• Teaming of InfiniBand, Wifi, WWAN not supported.
• Teams made up of teams not supported.

You can have team members in active or standby mode.

содрано отсюда: http://www.aidanfinn.com/?p=12924

3. Официальное чтиво:

https://gallery.technet.microsoft.com/Windows-Server-2016-839cb607/view/Discussions#content

1.1.1      Using VLANs

VLANs are a powerful tool that solves many problems for administrators. There are a few rules for using VLANs that will help to make the combination of VLANs and NIC Teaming a very positive experience.

1)       Anytime you have NIC Teaming enabled, the physical switch ports the host is connected to should be set to trunk (promiscuous) mode. The physical switch should pass all traffic to the host for filtering without modification.[1]

1)      Anytime you have NIC Teaming enabled, you must not set VLAN filters on the NICs using the NICs advanced properties settings. Let the teaming software or the Hyper-V switch (if present) do the filtering.

When using SET all VLAN settings must be configured on the VM’s switch port. 

1.1.1.1     VLANs in a Hyper-V host

This section applies only to NIC Teaming.  It does not apply to SET as a SET team has no team interfaces on which a VLAN may be enabled.

In a Hyper-V host VLANs should be configured only in the Hyper-V switch, not in the stand-alone NIC Teaming software. Configuring team interfaces with VLANs can easily lead to VMs that are unable to communicate on the network due to collisions with VLANs assigned in the Hyper-V switch.  Consider the following NIC Teaming example:

Figure 6 - VLAN misconfiguration (stand-alone NIC Teaming)

Figure 6 shows a common misconfiguration that occurs when administrators try to use team interfaces for VLAN support and also bind the team to a Hyper-V switch.  In this case VM C will never receive any inbound traffic because all the traffic destined for VLAN 17 is taken out at the teaming module.  All traffic except traffic tagged with VLAN 17 will be forwarded to the Hyper-V switch, but VM C’s inbound traffic never arrives.  This kind of misconfiguration has been seen often enough for Microsoft to declare this kind of configuration, i.e., VLANs exposed at the teaming layer while the team is bound to the Hyper-V switch, unsupported.  Repeat: If a team is bound to a Hyper-V switch the team MUST NOT have any VLAN-specific team interfaces exposed.  This is an unsupported configuration 

1.1.1.1     VLANs in a Hyper-V VM

1)      The preferred method of supporting multiple VLANs in a VM is to provide the VM multiple ports on the Hyper-V switch and associate each port with a VLAN. Never team these ports in the VM as it will certainly cause communication problems.

2)      If the VM has multiple SR-IOV VFs make sure they are on the same VLAN before teaming them in the VM. It’s easily possible to configure the different VFs to be on different VLANs and, like in the previous case, it will certainly cause communication problems.

3)      The only safe way to use VLANs with NIC Teaming in a guest is to team Hyper-V ports that are

a.      Each connected to a different external Hyper-V switch, and

b.      Each configured to be associated with the same VLAN (or all associated with untagged traffic only).

TIP: If you must have more than one VLAN exposed into a guest OS consider renaming the ports in the guest to indicate what the VLAN is. E.g., if the first port is associated with VLAN 12 and the second port is associated with VLAN 48, rename the interface Ethernet to be EthernetVLAN12 and the other to be EthernetVLAN48.  Renaming interfaces is easy using the Windows PowerShell Rename-NetAdapter cmdlet or by going to the Network Connections panel in the guest and renaming the interfaces

---

[1] Advanced users may choose to restrict the switch ports to only passing the VLANs present on the host.  While this may slightly improve performance in networks with many VLANs that the local host doesn’t access, it risks creating difficult to diagnose problems when, for example, a VM is migrated to a host and it uses a VLAN not previously present on the destination host.