Virtuelle Netzwerke und Zonen

Der virtuelle Switch sieht aus wie ein Switch und ist keiner

Die vSphere-Dokumentation nennt den Standard-Switch „einem physischen Ethernet-Switch sehr ähnlich“. Diese Ähnlichkeit ist echt und trotzdem die häufigste Fehlerquelle: An mindestens vier Stellen verhält er sich bewusst anders, und jede dieser Abweichungen erzeugt im Betrieb ein eigenes Symptom.

• Er lernt keine MAC-Adressen, er kennt sie aus der Konfiguration.
• Pakete an unbekannte Ziel-MAC werden verworfen, nicht geflutet.
• Er nimmt nicht am Spanning Tree Protocol teil.
• Er leitet keinen Verkehr zwischen zwei Uplinks weiter.

Wer ihn als kleinen physischen Switch behandelt, erwartet Flooding, Lernverhalten und Schleifenschutz — und diagnostiziert dann an der falschen Stelle. Dieses Modul geht die vier Abweichungen durch und zeigt, welche Betriebsentscheidung jeweils daran hängt.

Unbekannte Ziel-MAC wird verworfen, nicht geflutet

Ein physischer Switch, der eine Ziel-MAC nicht kennt, flutet das Paket auf allen Ports — so lernt er das Netz kennen. Ein virtueller Switch tut das nicht. Die Dokumentation ist an dieser Stelle unmissverständlich: Empfängt ein Port ein Paket mit unbekannter Ziel-MAC-Adresse, wird das Paket verworfen.

Das ist kein Versehen, sondern folgt aus der Bauweise. Der virtuelle Switch muss MAC-Adressen nicht lernen, weil er sie kennt: Jede vNIC hat eine konfigurierte MAC-Adresse, und der Switch weiß, an welchem Port sie hängt. Ein Lernverfahren wäre überflüssig — und Flooding wäre ein Sicherheitsproblem, weil es fremden Verkehr an alle VMs verteilte.

Für genau diesen Fall existiert die MAC-Learning-Richtlinie. Ist sie aktiv, prüft der Switch die Quell-MAC jedes Pakets, trägt sie in seine Tabelle ein und lässt das Paket passieren. Die Richtlinie ist damit kein allgemeiner Schalter für „besseres Netzwerken“, sondern die gezielte Antwort auf Umgebungen, in denen mehrere MAC-Adressen aus einer vNIC stammen.

Kein Spanning Tree — und warum das kein Mangel ist

Virtuelle Switches unterstützen STP nicht und nehmen nicht daran teil. Sie verhindern Schleifen auf anderem Weg: Ein virtueller Switch leitet keinen Verkehr von einem Uplink zu einem anderen weiter. Damit kann er keine Brücke zwischen zwei physischen Pfaden bilden — die Voraussetzung für eine Schleife fehlt.

Die praktische Folge betrifft die physische Seite. Ein Switchport, an dem ein Hypervisor-Uplink hängt, spricht mit einem Gegenüber, das nie eine BPDU beantwortet. Wer dort auf eine STP-Aushandlung wartet, verzögert nur den Portstart. Deshalb sind Einstellungen, die den Port sofort weiterleiten lassen, an diesen Ports üblich — die Entscheidung gehört aber dem Netzteam und braucht deren Bestätigung, nicht die Annahme des Virtualisierungsteams.

In der Linux-Welt ist dieselbe Entscheidung sichtbar in der Konfiguration: Eine Proxmox-Brücke trägt üblicherweise bridge-stp off und bridge-fd 0. Das Erste schaltet den Spanning Tree der Brücke ab, das Zweite setzt die Weiterleitungsverzögerung auf null — ein Port beginnt also sofort zu leiten, statt erst einen Lernzustand zu durchlaufen. Beides ist kein Leichtsinn, sondern folgt aus derselben Überlegung: Eine Brücke mit genau einem Uplink kann keine Schleife bilden.

Die Portgruppe ist der Vertrag, nicht das Kabel

Eine Portgruppe bündelt Ports mit gleicher Konfiguration: VLAN, Sicherheitseinstellungen, Teaming, Formung. Sie wird laut Dokumentation über ein Netzwerklabel identifiziert, das auf dem jeweiligen Host eindeutig sein muss.

Netzwerklabel — Der Name einer Portgruppe. Migration und Klonen ordnen eine vNIC über diesen Namen zu — nicht über VLAN-Nummer, Switch oder Uplink.

Daraus folgt die wichtigste Betriebsregel dieses Abschnitts: Gleicher Name heißt nicht gleiche Konfiguration. Existiert auf Host A eine Portgruppe Prod-Web mit VLAN 30 und auf Host B eine gleichnamige mit VLAN 130, migriert die VM anstandslos — und landet im falschen Netz. Die Zuordnung prüft die Gleichheit des Namens, nicht die Richtigkeit dahinter.

Umgekehrt gilt: Unterscheiden sich die Namen, scheitert die Migration sichtbar und früh. Das ist der angenehmere Fehler. Wer Namen vereinheitlicht, ohne die Konfiguration dahinter abzugleichen, tauscht einen lauten Fehler gegen einen stillen.

Drei Orte, an denen ein VLAN-Tag gesetzt werden kann

Ein VLAN-Tag kann im physischen Switch, im virtuellen Switch oder im Gast gesetzt werden. ESXi unterstützt alle drei, und die Wahl bestimmt, wer die Verantwortung trägt.

EST — External Switch Tagging

Der physische Switch taggt. Der Port zur VM ist untagged, die Portgruppe führt kein VLAN

VST — Virtual Switch Tagging

Der virtuelle Switch taggt eingehenden Verkehr mit der konfigurierten VLAN-ID und entfernt das Tag beim Verlassen. VLAN-ID 1 bis 4094

VGT — Virtual Guest Tagging

Der Gast verarbeitet VLAN-Verkehr selbst. Aktiviert wird das über die VLAN-ID 4095

VST ist der Normalfall: Die VM sieht ein ungetaggtes Netz und muss nichts wissen. VGT ist die Ausnahme für Gäste, die selbst mehrere VLANs terminieren — etwa eine virtuelle Firewall. Der Preis von VGT ist, dass die Netzkonfiguration in den Gast wandert und damit aus der Sicht der Plattform verschwindet.

Proxmox: eine VLAN-bewusste Brücke oder eine Brücke je VLAN

Proxmox VE setzt dieselbe Aufgabe mit Linux-Brücken um und kennt laut Dokumentation mehrere Modi. Der Unterschied ist im Betrieb deutlich spürbar.

Bei der VLAN-bewussten Brücke bekommt jede virtuelle Netzwerkkarte ein VLAN-Tag, das die Brücke transparent behandelt. Die Konfiguration in /etc/network/interfaces besteht aus zwei Zeilen an der Brücke:

• bridge-vlan-aware yes schaltet die Behandlung ein.
• bridge-vids 2-4094 legt fest, welche VLAN-IDs die Brücke überhaupt durchlässt.

Der zweite Wert wird gern übersehen. Er ist eine Positivliste: Ein Gast mit einem Tag außerhalb dieses Bereichs hat keine Verbindung, während Gäste innerhalb des Bereichs einwandfrei laufen. Das Symptom sieht nach einem Problem der einzelnen VM aus und steht tatsächlich in der Brückenkonfiguration.

Die traditionelle Variante erzeugt stattdessen je VLAN ein eigenes Gerät samt Brücke. Für VLAN 5 entstehen laut Dokumentation eno1.5 und vmbr0v5 — und diese Geräte bleiben bestehen, bis der Knoten neu startet. Wer VLANs häufig ändert, sammelt so verwaiste Schnittstellen an, die eine spätere Diagnose erschweren.

Teaming verteilt VMs, nicht Pakete

Der zweite große Irrtum betrifft die Bandbreite. Die Voreinstellung für die Lastverteilung heißt auf Standard- und Distributed-Switch Route Based on Originating Virtual Port. Der virtuelle Switch berechnet den Uplink aus der Port-ID der VM und der Anzahl der Uplinks im Team — und leitet danach laut Dokumentation immer über denselben Uplink, solange die VM auf demselben Port läuft.

Das ist in den meisten Umgebungen die richtige Wahl: Die Zuordnung ist berechenbar, verlangt nichts vom physischen Switch und verteilt viele VMs gleichmäßig. Wer die Grenze für eine einzelne VM überschreiten will, braucht ein anderes Verfahren — und die passende Konfiguration auf der Switchseite, die dann mitverhandelt werden muss.

Für die Diagnose folgt daraus eine nützliche Frage: Wenn eine VM an einer Bandbreitengrenze klebt, die verdächtig genau der eines einzelnen Uplinks entspricht, ist nicht das Team zu klein, sondern das Verfahren das erwartete.

Failback und Notify Switches: zwei Schalter mit Betriebsfolgen

Zwei Einstellungen des Teamings entscheiden, was bei einem Leitungsfehler passiert — und beide sind voreingestellt so, dass sie im Normalfall helfen und im Sonderfall schaden.

Notify Switches

Der virtuelle Switch meldet dem physischen Switch den Wechsel, damit dieser seine Lookup-Tabellen aktualisiert. Ohne diese Meldung läuft Verkehr weiter zum alten Port, bis die Tabelle altert

Failback

Voreinstellung Ja: Ein erholter Adapter kehrt sofort in den aktiven Zustand zurück und verdrängt den Standby-Adapter, der eingesprungen war

Die Voreinstellung für Failback ist bei einer sauberen Reparatur genau richtig. Bei einer flatternden Leitung dreht sie sich um: Jedes kurze Wiederkommen holt den Verkehr auf den defekten Adapter zurück, der ihn Sekunden später erneut verliert. Aus einem einmaligen Umschalten wird eine Kette von Unterbrechungen — und die Ursache sieht im Monitoring aus wie ein instabiles Gastsystem.

Der Preis der Gegenmaßnahme gehört genannt: Steht Failback auf Nein, bleibt der Verkehr nach der Reparatur auf dem Ersatzadapter. Das ist stabil, aber jemand muss die Rückkehr später bewusst herbeiführen — sonst läuft die Umgebung dauerhaft in einem Zustand, den niemand geplant hat.

MTU ist eine Eigenschaft des Pfades, nicht der Schnittstelle

Jumbo Frames werden üblicherweise mit einer MTU von 9000 konfiguriert. Der Wert steht an der Schnittstelle, gilt aber nur, wenn jedes Glied des Pfades ihn trägt: vNIC im Gast, Portgruppe beziehungsweise Brücke, virtueller Switch, Uplink, physischer Switch, Router und die Gegenstelle.

Ein einzelnes Glied mit kleinerer MTU erzeugt ein tückisches Fehlerbild: Kleine Pakete laufen, große nicht. Verbindungsaufbau und Anmeldung gelingen, die erste größere Übertragung bleibt stehen. Das sieht nach einem Anwendungsfehler aus und ist ein Pfadproblem.

Deshalb wird die MTU gemessen statt abgelesen. Ein Test mit einem Paket in Zielgröße und gesetztem Nicht-Fragmentieren-Bit zeigt die tatsächliche Pfad-MTU; die Konfigurationsanzeige zeigt nur, was jemand eingetragen hat.

Die Nutzlast wird dabei kleiner angegeben als die MTU, weil IP- und ICMP-Kopf mitzählen: 20 Byte IP plus 8 Byte ICMP ergeben 28 Byte Abzug. Für eine Ziel-MTU von 9000 prüft man also 8972 Byte Nutzlast:

• Linux im Gast: ping -M do -s 8972 <ziel> — -M do verbietet die Fragmentierung.
• Windows im Gast: ping -f -l 8972 <ziel> — -f setzt dasselbe Bit.
• Schlägt der Test fehl, während -s 1472 gelingt, liegt irgendwo im Pfad ein Glied mit Standard-MTU.

Kommt Overlay-Kapselung hinzu, sinkt die nutzbare MTU zusätzlich um den Overhead der Kapselung. Wer dann im Gast 9000 einträgt, hat rechnerisch bereits verloren: Der Gast erzeugt Pakete, die nach der Kapselung über der MTU des Underlays liegen. Die Kapselung muss deshalb beim Entwurf mitgerechnet und das Ergebnis anschließend gemessen werden.

Das Verwaltungsnetz hängt an dem Uplink, den du gerade änderst

Netzänderungen am Hypervisor haben eine Eigenschaft, die sie von fast allen anderen Änderungen unterscheidet: Der Pfad, über den du arbeitest, kann der Pfad sein, den du änderst. Eine falsche VLAN-Zuordnung an der Verwaltungsschnittstelle nimmt dir den Zugang zu genau dem Gerät, das du korrigieren müsstest.

• Vor der Änderung klären, über welchen Uplink und welche Portgruppe die Verwaltungsverbindung tatsächlich läuft — nicht, über welche sie laufen sollte.
• Einen zweiten Zugang bereithalten, der nicht über denselben Pfad führt: Konsole des Servers, Fernwartungskarte oder ein getrenntes Verwaltungsnetz.
• Änderungen an einem einzelnen Host prüfen, bevor sie auf den Cluster gehen.
• Den Rückweg vorher aufschreiben, nicht nach dem Verbindungsverlust rekonstruieren.

Diese Reihenfolge wirkt übervorsichtig, bis sie das erste Mal gebraucht wird. Der Aufwand ist klein, die Alternative ist ein Weg ins Rechenzentrum.

Arbeitsbeispiel: vNIC verbunden, Gateway unerreichbar

Das übertragbare Muster: Wenn ein Teil der Gäste funktioniert und ein anderer nicht, ist die trennende Eigenschaft die Spur. Sie zeigt die Schicht, in der die Ursache liegt — und erspart es, an der auffälligsten statt an der zuständigen Stelle zu suchen.