Broadcast- und Multicast-Stürme (Storms) sind einer der häufigsten Gründe für „plötzlich geht nichts mehr“ im Layer-2-Netz. Ursachen sind oft Loops, fehlerhafte Endgeräte, falsch konfigurierte NICs oder zu aggressive Discovery/Multicast-Anwendungen. Storm Control ist eine Cisco-Funktion, die die Rate von Broadcast, Multicast und Unknown-Unicast auf einem Port begrenzt. Damit schützt du Switch-CPU, Links und angrenzende Segmente – ohne STP oder andere Loop-Schutzmechanismen zu ersetzen. Richtig konfiguriert ist Storm Control ein effektiver „Notanker“ am Access.
Was Storm Control macht (und was nicht)
Storm Control überwacht die eingehende L2-Last pro Port-Kategorie und greift ein, wenn Schwellenwerte überschritten werden. Je nach Plattform kann der Switch Frames droppen oder den Port in einen Fehlerzustand versetzen.
- Begrenzt Broadcast, Multicast und/oder Unknown-Unicast pro Port
- Reduziert Impact von Loops und Fehlverhalten am Edge
- Ersetzt STP nicht, sondern ergänzt Loop- und Access-Security
Typische Storm-Quellen in der Praxis
- Layer-2-Loop (Patchkabel, Rogue-Switch)
- Fehlerhafte IoT-/Kamera-Geräte mit Broadcast-Flood
- Multicast-Anwendungen ohne sauberes Design
- MAC-Table-Instabilität (Unknown-Unicast Flooding)
Welche Traffic-Typen Storm Control begrenzt
Storm Control unterscheidet Kategorien, die du getrennt begrenzen kannst. Damit kannst du z. B. Broadcast sehr streng limitieren, Multicast moderat und Unknown-Unicast je nach Design.
- Broadcast: ARP, DHCP Discover, diverse Discovery-Protokolle
- Multicast: mDNS, SSDP, Multicast-Streaming, Routing-Protokolle (je nach Port)
- Unknown Unicast: Unicast zu unbekannten MACs (wird gefloodet wie Broadcast)
Warum Unknown-Unicast relevant ist
Wenn MAC-Tabellen durch Flapping oder Topology Changes instabil werden, steigt Unknown-Unicast Flooding stark an. Storm Control kann den Schaden begrenzen, bis die Ursache behoben ist.
Schwellenwerte verstehen: Prozent, pps und „Rising/Falling“
Je nach Plattform definierst du Storm Control als Bandbreitenanteil (Prozent) oder als absoluten Wert. Viele Cisco Switches nutzen „level“ mit Rising/Falling Threshold: Ab „Rising“ greift die Begrenzung, unter „Falling“ wird sie wieder aufgehoben.
Faustregeln für Access-Ports
- Broadcast eher streng (typisch niedrige Prozentwerte)
- Multicast moderat (abhängig von mDNS/Streaming im Netz)
- Unknown-Unicast vorsichtig (zu streng kann bei MAC-Learning-Events stören)
Storm Control konfigurieren: Praxis-Template für Edge-Ports
Ein sinnvoller Start ist, Storm Control auf klassischen Endgeräte-Ports zu aktivieren. Beginne konservativ und passe anhand von Monitoring/Logs an.
Beispiel: Broadcast/Multicast/Unknown-Unicast begrenzen
enable
configure terminal
interface range gigabitEthernet 1/0/1 - 24
description EDGE-CLIENTS
storm-control broadcast level 1.00 0.50
storm-control multicast level 2.00 1.00
storm-control unicast level 2.00 1.00
end
Was die Werte bedeuten
Bei Überschreiten von 1.00% Broadcast greift Storm Control, unter 0.50% wird wieder freigegeben. Analog für Multicast/Unknown-Unicast. Diese Werte sind Startwerte und müssen zum Netz passen.
Aktionen und Monitoring: Droppen vs. Shutdown verstehen
Storm Control kann je nach Plattform Traffic droppen und optional einen Trap/Log auslösen. In manchen Designs wird zusätzlich ein Port-Shutdown/Errdisable als harte Maßnahme genutzt, ist aber betriebsintensiver.
Storm-Control Status prüfen
show storm-control
show storm-control interface gigabitEthernet 1/0/10
Logs und Events prüfen
show logging | include STORM|storm-control|BCAST|MCAST
Wo Storm Control sinnvoll ist (und wo du vorsichtig sein solltest)
Storm Control ist besonders effektiv am Access-Rand, wo Loops und Fehlgeräte typischerweise entstehen. Auf Uplinks/Trunks musst du vorsichtig sein, weil dort legitimer Broadcast/Multicast aggregiert ankommt.
- Sinnvoll: Client-Ports, IoT-Ports, Drucker, Kameras
- Sinnvoll: Ports zu unmanaged Switches (wenn unvermeidbar)
- Vorsicht: Uplinks/Trunks (Traffic aggregiert, Thresholds werden schneller erreicht)
- Vorsicht: AP-Ports/Multicast-lastige Bereiche (mDNS/SSDP)
Sonderfall: Voice/PC Ports
VoIP benötigt selten hohe Broadcast-Raten, aber Multicast/Discovery kann je nach Telefonanlage relevant sein. Setze konservative Limits und beobachte Events.
Troubleshooting: Wenn Storm Control legitimen Traffic blockiert
Wenn Clients plötzlich „kurz weg“ sind oder bestimmte Dienste nicht funktionieren, kann ein zu strenges Storm Control die Ursache sein. Prüfe pro Port, ob Storm Control aktiv ist und ob es Events gab.
Diagnose-Spickzettel
show storm-control interface gigabitEthernet 1/0/10
show interfaces gigabitEthernet 1/0/10 | include rate
show mac address-table interface gigabitEthernet 1/0/10
show logging | include STORM|storm-control
Typische Ursachen für False Positives
- Thresholds zu niedrig (insbesondere Multicast bei mDNS/SSDP)
- Loop/Flapping erzeugt kurzfristig sehr hohe Flooding-Raten
- Viele Endgeräte booten gleichzeitig (ARP/DHCP Peaks)
Storm Control als Teil der Access-Härtung
Storm Control ist am stärksten in Kombination mit STP- und Access-Security-Standards. So reduzierst du sowohl die Wahrscheinlichkeit als auch den Impact von Storms.
- PortFast + BPDU Guard: verhindert viele Loop-Szenarien am Edge
- DHCP Snooping/DAI/IP Source Guard: reduziert Rogue- und Spoofing-Traffic
- Port Security: begrenzt unerwünschte MAC-Ausbreitung
- Storm Control: begrenzt den Rest-Impact (Notanker)
Edge-Port-Template (kombiniert)
configure terminal
interface gigabitEthernet 1/0/10
description EDGE-SECURED
switchport mode access
switchport access vlan 10
spanning-tree portfast
spanning-tree bpduguard enable
storm-control broadcast level 1.00 0.50
storm-control multicast level 2.00 1.00
storm-control unicast level 2.00 1.00
end
Best Practices: Storm Control sinnvoll dimensionieren
Storm Control wirkt nur dann gut, wenn die Schwellenwerte realistisch sind. Zu hoch bringt wenig Schutz, zu niedrig erzeugt Störungen. Starte konservativ, beobachte Events und passe pro Port-Typ an.
- Broadcast streng begrenzen, Multicast je nach Umfeld moderat
- Unknown-Unicast vorsichtig begrenzen (abhängig von MAC-Learning/TCNs)
- Auf Uplinks nur mit sehr bewusstem Design einsetzen
- Events loggen und regelmäßig auswerten
- Templates pro Port-Typ (Client/IoT/AP) statt „one size fits all“
copy running-config startup-config
Konfiguriere Cisco Router & Switches und liefere ein Packet-Tracer-Lab (CCNA)
Hallo! Ich bin ein CCNA-Network Engineer und unterstütze Sie bei Cisco Router- und Switch-Konfigurationen – inklusive eines vollständigen Cisco Packet-Tracer-Labs (.pkt). Ideal für Lern-/Übungsszenarien, Validierung oder eine saubere Demo-Topologie.
Was ich (je nach Paket) umsetze
-
Switching: VLANs, Trunking (802.1Q), Port-Zuweisung, STP-Basics (PortFast/BPDU Guard wo sinnvoll)
-
Routing: Default/Static Routing oder OSPF, Inter-VLAN Routing (Router-on-a-Stick)
-
Services: DHCP (Pools/Scopes), NAT/PAT für Internet-Simulation
-
Optional Security: Basic ACLs und SSH-Hardening
-
Test & Verifikation: Ping/Traceroute + wichtige Show-Commands (mit erwarteten Ergebnissen)
Sie erhalten
-
✅ Packet Tracer .pkt Datei
-
✅ Saubere Konfigurations-Notizen pro Gerät
-
✅ Verifikations-Checkliste + erwartete Outputs
-
✅ Kurze Dokumentation (wie die Topologie funktioniert)
Bitte schreiben Sie mir vor der Bestellung, damit wir Scope, Packet-Tracer-Version, Geräteanzahl und Deadline klären.
Konfiguriere Cisco Router & Switches | Cisco Packet-Tracer-Labs. Finden Sie mich auf Fiverr.
