1. Как создавать Team VLAN интерфейсы в Windows 2012/2016 (т.н VLAN Mode):
802.1q парсится на уровне Team-интерфейса (метод не поддерживается для Hyper-V vSwitch):
https://community.mellanox.com/docs/DOC-1845
2. Team Interfaces
1.1.1
Using VLANs
1.1.1.1
VLANs in a Hyper-V host
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
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:
 |
|
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.
