Eine Netzwerkschleife stoppen Sie sofort, indem Sie den verursachenden Access-Port am Switch shutdownen, danach Spanning Tree Protocol (STP), BPDU Guard und Loop Guard sauber aktivieren, redundante Doppelverkabelungen entfernen und LAG-Bündel prüfen. Anschließend läuft der Broadcast-Verkehr binnen Sekunden wieder auf normalem Niveau.
Symptome
- CPU-Last der Switches schnellt auf 90–100 %, Management-SSH reagiert träge oder gar nicht.
- Alle Ports blinken synchron und dauerhaft, obwohl kaum Nutzverkehr anliegt.
- VoIP-Telefone registrieren sich ab, DHCP-Leases scheitern, DNS-Abfragen laufen ins Timeout.
- MAC-Adressen springen im Sekundentakt zwischen mehreren Switchports (MAC-Flapping-Logs).
- Wireshark zeigt eine massive Broadcast- und ARP-Flut, oft mit denselben Frames in Endlosschleife.
Häufige Ursachen
Doppelt gepatchtes Access-Kabel
Ein Anwender oder Techniker steckt zwei Ports derselben Dose in denselben Switch oder verbindet zwei Access-Switches zusätzlich zur bestehenden Uplink-Leitung.
STP deaktiviert oder falsch priorisiert
Ohne aktives Spanning Tree oder mit einem billigen Consumer-Switch dazwischen blockiert niemand die redundanten Pfade, und Broadcasts kreisen unkontrolliert.
Fehlerhafte LAG- oder EtherChannel-Konfiguration
Nur eine Seite des Port-Channels ist konfiguriert oder die Modi (LACP active vs. on) passen nicht. Ergebnis: parallele, ungebündelte Links bilden eine Schleife.
Defektes SFP oder Kabel mit Signalreflexion
Ein sterbender Transceiver oder ein beschädigtes Patchkabel spiegelt Frames zurück und erzeugt so eine Pseudo-Schleife auf einem einzelnen Port.
Unmanaged Switch hinter der Dose
Anwender hängen einen Mini-Switch unter den Schreibtisch und schließen mehrere Kabel parallel an. STP-BPDUs werden nicht weitergereicht, die Schleife bleibt unsichtbar für das Coreequipment.
Schritt-für-Schritt-Lösung
- Sofort eingrenzen: Uplink-Auslastung und CPU-Load prüfen
Melden Sie sich am Coreswitch an und werten Sie CPU-Last sowie Broadcasts pro Sekunde aus, etwa mit "show processes cpu sorted" und "show interfaces counters". Ein einzelner Access-Switch mit 10.000+ Broadcasts/s ist Ihr Ausgangspunkt. - Verursachenden Port über MAC-Flapping-Logs finden
Suchen Sie im Syslog nach Meldungen wie "MAC flapping between port Gi1/0/12 and Gi1/0/24". Diese beiden Ports gehören zur Schleife. Prüfen Sie zusätzlich "show mac address-table" auf MAC-Adressen, die im Sekundentakt die Schnittstelle wechseln. - Schleife brechen: betroffenen Access-Port abschalten
Schalten Sie einen der beiden flappenden Ports gezielt ab: "interface Gi1/0/24" und "shutdown". Beobachten Sie CPU-Last und Broadcast-Zähler. Fällt die Last binnen Sekunden auf Normalniveau, war das die Schleife. Den zweiten Port lassen Sie aktiv, um den Nutzer nicht komplett abzuklemmen. - Physisch prüfen und aufräumen
Gehen Sie zur betroffenen Dose. Entfernen Sie doppelt gesteckte Patchkabel, kontrollieren Sie Unterschreibtisch-Switches auf Ringverkabelung und ersetzen Sie sichtbar beschädigte Kabel oder SFPs. Dokumentieren Sie die Änderung im Patchplan. - Spanning Tree sauber konfigurieren
Aktivieren Sie auf allen Switches Rapid PVST+ oder MSTP. Setzen Sie die STP-Priorität am Coreswitch fest niedrig (z. B. 4096), damit dieser garantiert Root Bridge ist. So wählt STP eindeutige, vorhersehbare Blocking-Ports statt zufälliger Pfadentscheidungen. - BPDU Guard, Loop Guard und Storm Control aktivieren
Konfigurieren Sie an allen Access-Ports "spanning-tree portfast" mit "spanning-tree bpduguard enable". Empfängt der Port unerwartet eine BPDU (typisch bei Loop-Verursachern), geht er automatisch in err-disable. Ergänzen Sie "storm-control broadcast level 1.00" als Notbremse. - LAG- und Uplink-Verbindungen kontrollieren
Prüfen Sie mit "show etherchannel summary" beide Seiten der Bündelung. Beide Enden müssen dieselbe Anzahl Ports, denselben Modus (LACP active/active) und dieselbe VLAN-Konfiguration tragen. Nicht gebündelte Parallel-Uplinks sind eine klassische Schleifenquelle. - Ergebnis verifizieren und Monitoring aufsetzen
Beobachten Sie CPU, Broadcast-Rate und STP-Topologie 15–30 Minuten lang. Legen Sie im Monitoring (z. B. LibreNMS, PRTG, Zabbix) Schwellwerte für Broadcast-Traffic, err-disable-Events und STP-Topology-Changes an. So bemerken Sie die nächste beginnende Schleife, bevor sie das Netz lahmlegt.
Schnelle Diagnose: Symptom, wahrscheinliche Ursache, direkte Maßnahme
| Symptom | Wahrscheinliche Ursache | Sofortmaßnahme |
|---|---|---|
| CPU 100 %, alle LEDs blinken synchron | Aktive L2-Schleife im Access-Bereich | Uplink zum verdächtigen Access-Switch temporär trennen |
| MAC flappt zwischen zwei Ports | Doppelt gepatchte Dose oder Ring-Verkabelung | Einen der beiden Ports shutdownen, Verkabelung prüfen |
| Port geht ständig in err-disable | BPDU Guard hat Loop-Verursacher erkannt | Kabel entfernen, Ursache klären, Port manuell aktivieren |
| Broadcast-Rate schwankt periodisch | STP-Topology-Changes durch instabilen Link | Log auf TCN-Events prüfen, defektes Kabel/SFP tauschen |
| Nur ein VLAN betroffen | Falsches VLAN-Trunking oder Native-VLAN-Mismatch | Trunk-Konfiguration beidseitig abgleichen |
| LAG bringt keine Bandbreite | LACP-Modi passen nicht | Beide Seiten auf identischen Modus (active/active) setzen |
So beugen Sie vor
- Access-Ports grundsätzlich mit PortFast plus BPDU Guard ausrollen, niemals ohne.
- Keine unmanaged Switches unter Schreibtischen zulassen, per Richtlinie und 802.1X absichern.
- Patchpläne aktuell halten und jede physische Änderung im Ticket dokumentieren.
- Storm Control für Broadcast, Multicast und Unknown Unicast als Standardprofil setzen.
Häufige Fragen
Woran erkenne ich einen Broadcast Storm sicher von einem DDoS-Angriff?
Ein Broadcast Storm bleibt in der Regel auf ein VLAN oder einen Standort begrenzt und zeigt sich als massive Layer-2-Broadcasts oder ARP-Frames zwischen internen MAC-Adressen. Ein DDoS trifft dagegen öffentliche IPs von außen und ist auf der WAN-Schnittstelle sichtbar. Ein kurzer Blick auf Wireshark oder NetFlow trennt beide Fälle innerhalb weniger Minuten.
Reicht Spanning Tree allein, um Netzwerkschleifen zu verhindern?
STP verhindert Schleifen zwischen Switches, die STP tatsächlich sprechen. Sobald ein unmanaged Consumer-Switch, ein defektes Kabel oder ein falsch konfigurierter WLAN-Bridge im Spiel ist, versagt es. Erst die Kombination aus STP, BPDU Guard, Loop Guard und Storm Control ergibt einen belastbaren Schutz gegen die typischen Praxisfälle.
Kann ich einen betroffenen Port einfach wieder aktivieren, sobald BPDU Guard ihn stillgelegt hat?
Nicht ohne Ursachenklärung. Ein err-disabled Port bedeutet, dass dort eine unerwartete BPDU angekommen ist, also eine Schleife oder ein fremder Switch. Klären Sie zuerst physisch, was am Kabelende hängt. Erst danach setzen Sie den Port mit "shutdown" und "no shutdown" oder per errdisable-Recovery-Timer zurück.