VLAN-Traffic unter Linux analysieren: Eine Anleitung

Informationen zu den Interfaces ermitteln

Die Analyse beginnt ohne Paketmitschnitt. Der Befehl ip link beschreibt die reale Netzwerktopologie. Bei solchen Untersuchungen sind die Beschaffung erster Informationen eine wichtige Basis für die weiteren Untersuchungen:

ip link show

Die Ausgabe zeigt alle Netzwerkgeräte mit administrativem und operativem Status. Flags wie LOWER_UP zeigen den physischen Link-Zustand. MASTER-Angaben zeigen die Einbindung in Bridges oder Bondings. Abweichungen zwischen erwartetem und tatsächlichem Status erklären viele VLAN Probleme bereits ohne Traffic Analyse.

Ebenfalls interessant in diesem Zusammenhang ist der Befehl:

ip link show type bridge

Dieser Befehl isoliert Bridge-Devices, wenn sie vorhanden sind. Er bestätigt, ob überhaupt eine Bridge existiert, aktiv ist und vom Kernel verwaltet wird. Fehlt eine Bridge hier, existiert sie aus Sicht des Datenpfads nicht. Das kann ein guter Einstieg in das Troubleshooting sein. Fehlende Bridges in der Ausgabe von ip link oder brctl zeigen, dass eine erwartete Layer-2-Weiterleitung im Kernel nicht existiert. In solchen Fällen erreichen Frames zwar physische Interfaces, werden jedoch nicht zwischen Ports verteilt. Das deutet auf eine fehlerhafte Konfiguration oder ein nicht initialisiertes Bridge Device hin. Eine weitere Untersuchung ist:

ip link show master br0

Die Ausgabe zeigt alle Ports, die Frames an die Bridge liefern oder von ihr empfangen. Fehlt ein Interface, erreicht dessen Traffic die Bridge nicht. Ein falscher Master weist auf eine fehlerhafte Zuordnung hin. Danach bringt der folgende Befehl weitere, wichtige Informationen:

ip link show type vlan

VLAN-Interfaces erscheinen als eigenständige Geräte. Die Ausgabe bestätigt VLAN ID, Parent Interface und operativen Status. Ist ein VLAN-Interface DOWN, werden Frames verworfen, auch wenn sie physisch eintreffen.

Bridge Verhalten nachvollziehen mit bridge-utils

Parallel liefern bridge-utils Einblicke in die Layer 2-Logik des Kernels. Das Tool brctl zeigt tatsächliche Lernprozesse:

brctl show

Installieren lassen sich die Tools mit:

sudo apt install bridge-utils

Die Ausgabe bestätigt, welche Ports aktiv an der Bridge teilnehmen. STP-Status zeigt, ob Ports weiterleiten oder blockieren. Ein Port im Blocking- oder Listening-Zustand nimmt Frames entgegen, leitet sie jedoch nicht weiter. Hier hilft:

brctl showmacs br0

Diese Tabelle zeigt erlernte MAC-Adressen mit Portbindung und Alter. Jeder Eintrag bestätigt realen Traffic auf dem jeweiligen Port. Bleibt die Tabelle leer oder unvollständig, empfängt die Bridge keine Frames oder verwirft sie vor dem Lernen. Ebenfalls wichtig ist:

brctl showstp br0

Der STP-Zustand erklärt Verzögerungen oder vollständige Blockaden. Ports im Learning Zustand akzeptieren Frames, leiten sie jedoch nicht weiter. In VLAN-Szenarien mit redundanten Pfaden erklärt dies scheinbar zufällige Paketverluste.

VLAN-Filterung und Weiterleitung prüfen

Bei VLAN-fähigen Bridges entscheidet die VLAN-Konfiguration über Weiterleitung. Die Befehle ip link und bridge liefern diese Informationen direkt aus dem Kernel.

Die Ausgabe enthält VLAN-Filtering und Default-PVID (Port VLAN ID). Ist VLAN-Filtering aktiv, akzeptiert die Bridge nur explizit konfigurierte VLANs. Fehlt ein VLAN-Eintrag, werden Frames verworfen, obwohl sie physisch eintreffen:

bridge vlan show

Diese Ansicht zeigt VLAN-Mitgliedschaften pro Port. Trunk-Ports tragen mehrere VLAN IDs. Access Ports haben eine einzelne VLAN-ID mit gesetztem PVID. Eine falsche PVID führt dazu, dass ungetaggte Frames einem unerwarteten VLAN zugeordnet werden:

bridge vlan show dev eth0

Die Ausgabe zeigt VLAN-Regeln für ein einzelnes Interface. Dies erlaubt die gezielte Prüfung eines Trunk-Ports ohne Ablenkung durch andere Ports.

Paketfluss sichtbar machen mit tcpdump

Das Tool tcpdump erfasst Pakete exakt an dem Interface, an dem der Mitschnitt gestartet wird, und zeigt nur den Traffic, der diesen Punkt im Kernel tatsächlich passiert. Ein Mitschnitt auf einem physischen Port zeigt eingehende und ausgehende Frames vor Bridge- und VLAN-Verarbeitung, ein Mitschnitt auf einer Bridge oder einem VLAN-Interface listet Traffic nach interner Weiterleitung oder Enttaggung. Ohne korrekte Wahl des Interfaces lassen sich Ursachen nicht zuordnen, da unterschiedliche Capture-Punkte unterschiedliche Verarbeitungsstufen abbilden:

tcpdump -D

Der Befehl weist tcpdump an, alle vom libpcap erreichbaren Capture-Interfaces aufzulisten. Das umfasst physische NICs, VLAN-Interfaces, Bridge-Ports, Bond-Slaves und virtuelle Geräte. Das Tool tcpdump greift dabei nicht auf die logische Netzwerkkonfiguration zu, sondern auf die tatsächlichen Hook-Punkte im Kernel, an denen Pakete abgegriffen werden können. Die Ausgabe dient dazu, den korrekten Mitschnittpunkt zu bestimmen, bevor überhaupt Traffic analysiert wird. Wird ein falsches Interface gewählt, fehlen VLAN-Tags, Bridge-Traffic oder komplette Paketströme, obwohl sie real vorhanden sind.

Die Liste aller Capture Interfaces zeigt, welche Geräte tcpdump direkt erreicht. Bridge Ports und VLAN Devices erscheinen separat und erlauben gezielte Mitschnitte. Der Befehl

sudo tcpdump -i eth0 -e -n

startet einen Paketmitschnitt direkt auf dem physischen Interface eth0 und greift die Frames vor jeder Bridge-, VLAN- oder IP-Weiterverarbeitung im Kernel ab. Der Parameter -i eth0 legt dieses Interface als Capture-Quelle fest und schließt jede interne Umlenkung über Bridges oder VLAN-Devices aus. Der Parameter -e erzwingt die Ausgabe des Ethernet-Headers, also Quell- und Ziel-MAC-Adresse sowie vorhandene 802.1Q-VLAN-Tags. Ohne -e wären VLAN-Informationen nicht sichtbar, was eine Analyse auf Layer 2 unmöglich macht. Der Parameter -n unterbindet jede Namensauflösung für IP-Adressen und Ports, sodass tcpdump keine DNS- oder Service-Lookups ausführt und die Ausgabe exakt den numerischen Werten entspricht, die im Paket stehen.

Der Mitschnitt auf dem physischen Interface zeigt rohe Ethernet-Frames. Der Parameter -e erzwingt die Anzeige von MAC-Headern und VLAN-Tags. Diese Sicht zeigt, ob Frames den Host überhaupt erreichen. Danach ist der folgende Befehl hilfreich:

tcpdump -i eth0 -e -n vlan

Dieser Filter isoliert VLAN getaggte Frames. Die VLAN-ID erscheint direkt in der Ausgabe. Fehlen VLAN-Tags hier, liegt das Problem außerhalb des Hosts oder bei NIC-Offloads. In diesem Fall kann die Bridge mitgeschnitten werden:

tcpdump -i br0 -e -n

Der Mitschnitt auf der Bridge zeigt Frames nach interner Verarbeitung. Unterschiede zum physischen Interface zeigen Filterung, STP-Effekte oder Port Isolation:

tcpdump -i eth0.20 -n

Der Mitschnitt auf einem VLAN-Interface zeigt Frames bereits ohne VLAN-Tag. Damit lässt sich überprüfen, ob die VLAN-Verarbeitung im Kernel korrekt erfolgt und die Frames den höheren Protokollschichten zur Verfügung gestellt werden.

Auswirkungen von NIC-Offloads gezielt prüfen

Bei der VLAN-Analyse verfälschen aktive NIC-Offloads häufig den Mitschnitt. Der Kernel verarbeitet Frames logisch anders, als sie physisch erscheinen. Vor jeder Interpretation von tcpdump-Ausgaben muss deshalb geprüft werden, welche Offloads aktiv sind:

ethtool -k eth0

Dieser Befehl zeigt die vom Netzwerkkartentreiber unterstützten und aktuell aktiven Offload-Funktionen für das Interface eth0.

Für VLAN-Analysen sind vor allem tx-vlan-offload und rx-vlan-offload relevant. Ist tx-vlan-offload aktiviert, fügt die Netzwerkkarte VLAN-Tags erst nach dem Punkt hinzu, an dem tcpdump Pakete erfasst. Ein Mitschnitt auf eth0 zeigt daher ungetaggte Frames, obwohl sie tatsächlich mit VLAN-Tags übertragen werden. Ohne diese Prüfung kann ein vermeintlich fehlendes VLAN-Tag schnell zu einer falschen Diagnose führen.

Promiscuous Mode für vollständige Sicht aktivieren

In Bridge- oder Trunk-Szenarien transportiert ein Interface häufig Frames, deren Ziel-MAC-Adresse nicht der eigenen Adresse entspricht. Ohne aktivierten Promiscuous Mode verwirft der Netzwerktreiber solche Frames, bevor sie von tcpdump erfasst werden können:

ip link set dev eth0 promisc on

Dieser Befehl versetzt das Interface eth0 in den Promiscuous Mode. Der Treiber leitet nun alle empfangenen Frames unabhängig von der Ziel-MAC-Adresse an den Kernel weiter. Erst damit ist sichergestellt, dass tcpdump den vollständigen Layer-2-Traffic sieht, den die Bridge oder das VLAN tatsächlich verarbeitet.

MTU als Fehlerquelle ausschließen

VLAN-Tagging erhöht die Framegröße um vier Byte. Ist die MTU zu knapp konfiguriert, verwirft der Kernel Frames oder fragmentiert sie, bevor sie die Bridge passieren:

ip link set dev eth0 mtu 1500

Mit diesem Befehl wird die MTU explizit gesetzt, um unklare Zustände zu vermeiden. In VLAN-Umgebungen mit Trunks und Bridges zeigt eine inkonsistente MTU häufig Symptome, die wie Paketverlust oder Bridge-Fehlverhalten aussehen, tatsächlich aber auf Größenüberschreitungen beruhen.

Systematischer Diagnosepfad bei fehlendem VLAN-Traffic

Ein VLAN-Interface empfängt keinen Traffic. Die Analyse beginnt immer am frühestmöglichen Punkt im Datenpfad:

tcpdump -i eth0 -e -n vlan 20

Dieser Mitschnitt prüft, ob VLAN-Frames mit der ID 20 das physische Interface erreichen. Der Parameter -i eth0 legt den Capture-Punkt fest, -e zeigt den Ethernet-Header inklusive VLAN-Tag und -n verhindert jede Namensauflösung. Ist hier kein Traffic sichtbar, liegt das Problem außerhalb des Hosts:

tcpdump -i br0 -e -n vlan 20

Dieser Mitschnitt prüft, ob die Bridge den VLAN-Traffic intern weiterleitet. Erscheint der Traffic auf eth0, aber nicht auf br0, blockiert die Bridge die Frames aufgrund von VLAN-Filterung, STP-Zustand oder Portkonfiguration:

bridge vlan show

Dieser Befehl zeigt die VLAN-Mitgliedschaften aller Bridge-Ports. Fehlt VLAN 20 an einem Port oder ist kein PVID gesetzt, verwirft die Bridge die Frames bewusst. Die Ausgabe liefert hier die direkte Erklärung für das beobachtete Verhalten:

brctl showmacs br0

Die MAC-Tabelle der Bridge zeigt, ob Frames aus VLAN 20 überhaupt gelernt werden. Fehlen Einträge, empfängt die Bridge keine Frames aus diesem VLAN oder das Lernen ist deaktiviert. Die Tabelle bestätigt damit, ob Traffic real durch die Bridge läuft:

tcpdump -i eth0.20 -n

Dieser Mitschnitt prüft das VLAN-Interface selbst. Bleibt er leer, obwohl der Traffic auf der Bridge sichtbar ist, liegt das Problem zwischen Bridge und VLAN-Device, etwa durch falsche Bindung, Down-Status oder fehlerhafte VLAN-Zuordnung.

Zusammenspiel der Werkzeuge im Betrieb

Die methodische Kombination aus Konfigurationsprüfung via ip link, Einsicht in die Weiterleitungslogik des Kernels durch bridge-utils und Live-Paketerfassung mit tcpdump ermöglicht ein lückenloses Troubleshooting von VLAN-Strukturen. Fehlinterpretationen durch Hardware-Offloading werden ausgeschlossen. Die Steuerung ist plattformübergreifend – auch via PowerShell – effizient möglich.