Ein Netzwerk-Bridge-Ausfall lässt sich meist beheben, indem Sie den Status der Bridge-Schnittstelle prüfen, die zugewiesenen Ports und IP-Konfiguration kontrollieren, STP-Konflikte auflösen und Treiber sowie Firmware aktualisieren. Danach die Bridge neu erstellen oder den Netzwerkdienst neu starten stellt die Verbindung in den meisten Fällen wieder her.
Symptome
- Endgeräte hinter der Bridge erhalten keine IP-Adresse mehr per DHCP.
- Ping zwischen den überbrückten Segmenten läuft in Timeouts oder verliert Pakete sporadisch.
- Die Bridge-Schnittstelle zeigt Status „down" oder „unknown" trotz aktiver physischer Ports.
- Extrem hohe CPU-Last auf dem Bridge-Host, oft begleitet von Broadcast-Flut im Switch-Log.
- Nur ein Teil des Traffics passiert die Bridge, etwa ARP kommt an, TCP-Sessions bauen aber nicht auf.
Häufige Ursachen
Falsch zugeordnete Bridge-Ports
Eine Schnittstelle wurde der Bridge nicht hinzugefügt oder trägt noch eine eigene IP-Adresse. Damit fehlt der Layer-2-Pfad, obwohl das Kabel physisch steht.
STP-Konflikt oder Loop
Zwei aktive Pfade zwischen denselben Segmenten erzeugen einen Broadcast-Sturm. STP blockiert den falschen Port oder ist auf einer Seite deaktiviert.
Defekter Treiber oder alter NIC-Firmware-Stand
Bestimmte Realtek- und Intel-Treiber unterstützen Promiscuous-Mode fehlerhaft, was Bridging unter Windows und Linux komplett blockiert.
MAC-Adressfilter oder Port-Security
Der Uplink-Switch akzeptiert nur eine MAC pro Port. Sobald die Bridge mehrere Client-MACs weiterleitet, schaltet der Port in err-disabled.
Firewall blockiert Forwarding
Auf Linux verhindert eine restriktive FORWARD-Chain in iptables/nftables das Durchreichen. Unter Windows kollidieren Defender-Firewall-Profile mit der Bridge-Schnittstelle.
Schritt-für-Schritt-Lösung
- Physische Verbindungen und Link-Status verifizieren
Prüfen Sie zuerst die LEDs an NIC und Switch-Port. Tauschen Sie das Patchkabel gegen ein bekannt gutes. Unter Linux zeigt `ip -br link` den Operational State, unter Windows `Get-NetAdapter` in PowerShell. Ein Port im Status „NotPresent" deutet auf einen Treiberausfall hin, nicht auf ein Kabelproblem. - Bridge-Mitgliedschaft der Interfaces kontrollieren
Listen Sie die zugeordneten Ports auf: Linux mit `bridge link show` oder `ip link show master br0`, Windows über `Get-NetAdapterBinding` und die Adaptereigenschaften. Jedes Mitglied darf keine eigene IPv4- oder IPv6-Adresse mehr tragen. Die IP gehört ausschließlich auf das Bridge-Interface selbst. - IP-Konfiguration und Gateway prüfen
Weisen Sie der Bridge eine gültige Adresse im richtigen Subnetz zu und tragen Sie ein erreichbares Gateway ein. Testen Sie mit `ping` zum Gateway und `arping` zu einem Nachbargerät. Fehlt die Antwort im ARP, arbeitet der Layer-2-Pfad nicht sauber weiter. - Spanning Tree und mögliche Loops entschärfen
Aktivieren Sie STP auf der Bridge (`ip link set br0 type bridge stp_state 1`) und beobachten Sie den Portstatus für rund 30 Sekunden. Trennen Sie testweise redundante Uplinks. Findet der Switch plötzlich wieder eine stabile MAC-Tabelle, war ein Loop die Ursache. - Treiber und NIC-Firmware aktualisieren
Laden Sie den aktuellen Treiber direkt vom Hersteller, nicht über die generische Windows-Update-Version. Unter Linux prüfen Sie mit `ethtool -i eth0` die Firmware-Revision. Nach dem Update Rechner neu starten und Bridge neu anlegen, damit der Promiscuous-Mode korrekt registriert wird. - Firewall- und Forwarding-Regeln freigeben
Setzen Sie unter Linux `sysctl -w net.ipv4.ip_forward=1` und prüfen Sie `nft list ruleset` auf blockierende FORWARD-Regeln. Für Bridging zusätzlich `net.bridge.bridge-nf-call-iptables` bewusst einstellen. Unter Windows deaktivieren Sie testweise das Firewall-Profil der Bridge-Schnittstelle. - Bridge sauber neu aufbauen
Bringt keine der Prüfungen Erfolg, löschen Sie die Bridge komplett und legen sie neu an. Linux: `ip link del br0`, dann `ip link add name br0 type bridge` und Ports mit `ip link set eth0 master br0` zuweisen. Windows: Bridge in „Netzwerkverbindungen" entfernen und Adapter erneut markieren. - Gegenprüfung mit Paketmitschnitt
Starten Sie `tcpdump -i br0 -n` auf dem Bridge-Host und pingen Sie durch. Sehen Sie Request, aber keine Reply, liegt das Problem hinter der Bridge. Fehlt der Request bereits, blockiert der Host selbst. Diese Aufteilung spart Stunden bei sporadischen Fällen.
Symptom, wahrscheinliche Ursache und erster Fix bei Bridge-Störungen
| Symptom | Wahrscheinliche Ursache | Erste Maßnahme |
|---|---|---|
| Bridge-Interface bleibt down | Kein Port zugeordnet oder Treiber inaktiv | Mitgliedschaft prüfen, Treiber neu laden |
| Broadcast-Sturm, hohe CPU | Layer-2-Loop | STP aktivieren, redundanten Uplink trennen |
| Kein DHCP hinter der Bridge | Forwarding deaktiviert oder Firewall blockt | ip_forward=1, FORWARD-Regeln prüfen |
| Switch-Port geht in err-disabled | Port-Security limitiert MAC-Anzahl | MAC-Limit erhöhen oder Port-Security anpassen |
| Verbindung bricht nach Update ab | NIC-Treiber unterstützt Promiscuous fehlerhaft | Treiber-Rollback oder Herstellerversion einspielen |
| Nur ARP, kein TCP | MTU-Mismatch auf Bridge | MTU auf allen Ports angleichen |
So beugen Sie vor
- Bridge-Konfiguration in Ansible oder Netplan versionieren, statt manuell in der GUI zu klicken.
- STP grundsätzlich aktiv lassen, auch bei nur einem Uplink, als Schutz gegen versehentliche Loops.
- Treiber- und Firmware-Stand der NICs quartalsweise prüfen und dokumentieren.
- Monitoring auf Interface-Errors und Broadcast-Rate einrichten, etwa mit LibreNMS oder Zabbix.
Häufige Fragen
Warum funktioniert meine Windows-Bridge nach einem Feature-Update nicht mehr?
Feature-Updates ersetzen häufig den Netzwerkadaptertreiber durch eine generische Microsoft-Version, die den für Bridging nötigen Promiscuous-Mode nicht sauber implementiert. Deinstallieren Sie den Treiber, laden Sie die aktuelle Version direkt beim NIC-Hersteller und legen Sie die Bridge danach neu an. Vorher gespeicherte Bridge-Objekte bleiben oft als Karteileichen zurück und müssen manuell entfernt werden.
Sollte ich STP auch bei nur einer Bridge aktivieren?
Ja. STP kostet praktisch keine Ressourcen, schützt aber gegen versehentliche Loops, etwa wenn jemand zwei Ports desselben Switches mit einem Kabel verbindet. Ohne STP kann ein einziger Fehlgriff das gesamte Segment lahmlegen. Der zusätzliche Aufwand beim Portstatus-Wechsel von rund 30 Sekunden lässt sich durch RSTP oder Portfast weiter reduzieren.
Wann sollte ich statt einer Software-Bridge einen echten Switch einsetzen?
Sobald mehr als zwei bis drei Segmente dauerhaft verbunden werden oder der Durchsatz 1 Gbit/s pro Port übersteigt, wird eine Software-Bridge zum Flaschenhals. CPU-Last, unklare QoS und fehlende Hardware-Beschleunigung führen zu Paketverlust. Ein managed Switch bietet dann deterministische Latenz, VLAN-Trennung und bessere Diagnose über SNMP.