Wenn das VLAN-tagging eines unter Hyper-V angelegten SET-Switches nicht mehr funktioniert (oder nur in eine Richtung), kann das an einem „Optionalen Update“ von Windows Update liegen! Es fällt leider auf, dass hier vermehrt sehr alte Treiber ausgeliefert werden.

Im Falle einer Realtek-NIC war ein so optional angebotener Treiber irgendwann installiert worden. Der Treiber war offensichtlich so alt, dass er nicht sauber mit Hyper-V bzw. der SET-Switch-Technologie zusammenarbeitete. Alle (von der NIC) ausgehenden Frames erhielten entweder gar keinen VLAN-Tag oder nur ausgehend einen Tag. Eingehende getaggte Frames wurden verworfen. In gängigen DHCP-Serverimplementierungen zeigt sich das am Status „Offered“, wenn zumindest die Richtung zum DHCP funktioniert, aber vom Client keine Bestätigung zurückkommt (weil dieser die Antwort gar nicht erhalten hat).

Die Lösung war in diesem Fall, direkt von Reaktek die aktuellsten Treiber zu downloaden. Danach war das eigenwillige Verhalten weg.

 

---

Korrekter Ablauf eines DHCP-Handshakes von einem Hyper-V-VLAN-tagged-Interface:

 

 

 

 

 

---

WICHTIG

In der erweiterten Konfiguration der physischen NIC(s) muss die Option „Priorität und VLAN“ aktiv sein.

Dieser Wert kann auch direkt in der Registry unter:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\00nn
*PriorityVLANTag

eingestellt werden, die Werte lauten:

• 0 – Priority & VLAN Disabled
• 1 – Priority Enabled
• 2 – VLAN Enabled
• 3 – Priority & VLAN Enabled

 

Und wer unter Windows mit WireShark VLAN-Tags auswerten möchte und in der Registry den Wert:

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\00nn
MonitorModeEnabled

auf „1“ stehen hat, bei dem funktionieren die VLAN-Interfaces u. U. auch nicht richtig!
Dieser Eintrag wird benötigt damit VLAN-Tags nicht vom Treiber entfernt werden und in WireShark sichtbar bleiben.