19
Ursache für Auslösung Storm-Control Cisco SG350X
Hallo zusammen,
heute morgen gab es bei uns einen unplanmäßigen Stomausfall, der zum ungraceful-Shutdown der Server sowie der Switche (2 gestackte SG350) führte. Nach Wiederhochfahren des Systems kam es ca 1 Stunde später nacheinander zum Auslösen der Storm-Control an den Ports von 4 Desktop-PCs (Windows 10). Hat jemand eine Idee, was die Ursache sein könnte? eine Schleife am Switch, die ja als häufigste Ursache genannt wird, kann es wohl nicht sein. Und das nacheinander 4 Netzwerkkarten Defekt sind ist ja auch unwahrscheinlich (4x Onboard Realtek).
Leuchtet bei einem von Euch die Glaskugel? Ich habe gerade keine Idee, wo ich suchen soll.
Grüße
lcer
heute morgen gab es bei uns einen unplanmäßigen Stomausfall, der zum ungraceful-Shutdown der Server sowie der Switche (2 gestackte SG350) führte. Nach Wiederhochfahren des Systems kam es ca 1 Stunde später nacheinander zum Auslösen der Storm-Control an den Ports von 4 Desktop-PCs (Windows 10). Hat jemand eine Idee, was die Ursache sein könnte? eine Schleife am Switch, die ja als häufigste Ursache genannt wird, kann es wohl nicht sein. Und das nacheinander 4 Netzwerkkarten Defekt sind ist ja auch unwahrscheinlich (4x Onboard Realtek).
Leuchtet bei einem von Euch die Glaskugel? Ich habe gerade keine Idee, wo ich suchen soll.
Grüße
lcer
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 1578543999
Url: https://administrator.de/contentid/1578543999
Printed on: April 24, 2024 at 10:04 o'clock
19 Comments
Latest comment
Sicher das die User nicht was an den Netzwerkkabeln gemacht haben!
Hatte das auch mal - Stromausfall nur im Serverraum und die user haben dann in den Büros selbst mal alle kabel neu gesteckt wg. Fehlersuche - aber leider auch ne Schleife eingebaut.
Hatte das auch mal - Stromausfall nur im Serverraum und die user haben dann in den Büros selbst mal alle kabel neu gesteckt wg. Fehlersuche - aber leider auch ne Schleife eingebaut.
Waren das Ports an denen Endgeräte mit einem LACP LAG verbunden waren ? Möglich das dann dort mal ein kurzzeitiger Loop aufgetreten ist beim Reboot solcher Maschinen.
Möglich auch das das Ports mit kaskadierten Desktop Switches u.ä. waren und dort ein Loop ausgelöst wurde.
Eine Analyse ist mit den sehr spärlichen Daten sehr schwer da man weder Eimnzelheiten deiner Topologie kennt noch die Triggerpunkte deiner Stormcontrol und daraus resultierende Log oder Syslog Messages. Unter solchen Rahmenbedingungen bleibt dann auch uns häufig nur die Kristallkugel.
Möglich auch das das Ports mit kaskadierten Desktop Switches u.ä. waren und dort ein Loop ausgelöst wurde.
Eine Analyse ist mit den sehr spärlichen Daten sehr schwer da man weder Eimnzelheiten deiner Topologie kennt noch die Triggerpunkte deiner Stormcontrol und daraus resultierende Log oder Syslog Messages. Unter solchen Rahmenbedingungen bleibt dann auch uns häufig nur die Kristallkugel.
heute morgen gab es bei uns einen unplanmäßigen Stomausfall, der zum ungraceful-Shutdown der Server sowie der Switche
Hat die USV (die hoffentlich da dran ist) ebenfalls versagt????
Ansonsten würde ich die Switche mal kontrolliert in der entsprechenden Reihenfolge neu starten (sofern das im lfd. Betrieb möglich ist).
Gruß
Looser
Hallo,
Die Topologie ist eigentlich ganz einfach. 2 Switche als Stack. Daran ein Mikrotik-Switch, zu dem 2 VLANs durchgereicht werden. LACP/LAG läuft für zwei Hyper-V Hosts. Keine Desktop-Switche.
Die USV hat übrigens versagt, nachdem die Mitarbeiter zum beheben des Piepens im Serverschrank den FI-Schutzschalter ausgeschaltet haben, nachdem der Strom gerade wieder da war. OK Unterdimensioniert. Wobei die Switche keine Shutdownfunktion haben und immer "hart" ausgehen.
Die Einstellungen sind: Rate Threshold 100000 kbits/sec für Unknown Unicast, Multicast, Broadcast. Auslöser waren der Statistik zufolge Unknown Unicast Storm Control.
Unknown Unicasts - wären das dann eventuell Verbindungsversuche zu Geräten, der MAC noch in der ARP-Tabelle auf dem Client liegen, aber wegen des Switch - Neustarts dort (noch) unbekannt waren? Ich hatte nicht alle Geräte sofort neu gestartet.
Grüße
lcer
Grüße
lcer
Die Topologie ist eigentlich ganz einfach. 2 Switche als Stack. Daran ein Mikrotik-Switch, zu dem 2 VLANs durchgereicht werden. LACP/LAG läuft für zwei Hyper-V Hosts. Keine Desktop-Switche.
Die USV hat übrigens versagt, nachdem die Mitarbeiter zum beheben des Piepens im Serverschrank den FI-Schutzschalter ausgeschaltet haben, nachdem der Strom gerade wieder da war. OK Unterdimensioniert. Wobei die Switche keine Shutdownfunktion haben und immer "hart" ausgehen.
Die Einstellungen sind: Rate Threshold 100000 kbits/sec für Unknown Unicast, Multicast, Broadcast. Auslöser waren der Statistik zufolge Unknown Unicast Storm Control.
Unknown Unicast Storm Control
Bytes Passed: 13617557
Bytes Dropped: 3264131
Last Drop Time: 2021-Dec-02 08:57:19Unknown Unicasts - wären das dann eventuell Verbindungsversuche zu Geräten, der MAC noch in der ARP-Tabelle auf dem Client liegen, aber wegen des Switch - Neustarts dort (noch) unbekannt waren? Ich hatte nicht alle Geräte sofort neu gestartet.
Grüße
lcer
Grüße
lcer
Die USV hat übrigens versagt, nachdem die Mitarbeiter zum beheben des Piepens im Serverschrank den FI-Schutzschalter ausgeschaltet haben
und die haben jetzt noch alle Finger?????
Zitat von @Looser27:
und die haben jetzt noch alle Finger?????
bei der aktuellen Arbeitsmarktsituation: ja!Die USV hat übrigens versagt, nachdem die Mitarbeiter zum beheben des Piepens im Serverschrank den FI-Schutzschalter ausgeschaltet haben
und die haben jetzt noch alle Finger?????
Grüße
lcer
Daran ein Mikrotik-Switch, zu dem 2 VLANs durchgereicht werden. LACP/LAG läuft für zwei Hyper-V Hosts. Keine Desktop-Switche.
MT nur einbeinig oder auch redundant mit LACP LAG und mit je einem Bein auf einen der Stack Member ?Waren diese Ports davon betroffen ?
Warum hängen die Switches nicht mit an der USV ? Wäre doch sinnig ?!
Zitat von @aqui:
einbeinig an nur einem Switch, nicht-redundant, kein LACPDaran ein Mikrotik-Switch, zu dem 2 VLANs durchgereicht werden. LACP/LAG läuft für zwei Hyper-V Hosts. Keine Desktop-Switche.
MT nur einbeinig oder auch redundant mit LACP LAG und mit je einem Bein auf einen der Stack Member ?Waren diese Ports davon betroffen ?
nein. auch keine am Miktorik-SwitchWarum hängen die Switches nicht mit an der USV ? Wäre doch sinnig ?!
Tun sie doch. Doch die SG350Xer haben keine Power-OFF/Shutdown-Funktion. Die gehen dann mit der USV direkt aus.Grüße
lcer
Weisst du denn WAS für Endgeräte an den betroffenen Ports hängen ?
Hallo,
Siehe oben. Einfache Windows 10 PCs ohne Extras ( kein Virtueller Switch, kein Linux subsystem etc). Es sind auch alle Kabel überprüft: Kein Desktopswitch, kein IP-Telefon.
Grüße
lcer
Siehe oben. Einfache Windows 10 PCs ohne Extras ( kein Virtueller Switch, kein Linux subsystem etc). Es sind auch alle Kabel überprüft: Kein Desktopswitch, kein IP-Telefon.
Grüße
lcer
Da wirds dann schwer ohne Traces oder detailiertes Logging. Wenns nur ein einmaliges Ereignis war kannst du das wohl beruhigt ignorieren und auf einen Folgefehler des Shutdowns schieben.
Nur nebenbei:
Spanning Tree im Single Span Verfahren mit RSTP und mit Root Priority (z.B. 8192) auf den Cisco Stack hast du auf beiden Switches aktiviert ?! (Loop Prevention)
Nur nebenbei:
Spanning Tree im Single Span Verfahren mit RSTP und mit Root Priority (z.B. 8192) auf den Cisco Stack hast du auf beiden Switches aktiviert ?! (Loop Prevention)
Hallo,
Grüße
lcer
Zitat von @aqui:
Da wirds dann schwer ohne Traces oder detailiertes Logging. Wenns nur ein einmaliges Ereignis war kannst du das wohl beruhigt ignorieren und auf einen Folgefehler des Shutdowns schieben.
Ist bis jetzt nicht wieder aufgetreten. Ich sitz es mal aus. Trace-Logs gibt es natürlich nicht.Da wirds dann schwer ohne Traces oder detailiertes Logging. Wenns nur ein einmaliges Ereignis war kannst du das wohl beruhigt ignorieren und auf einen Folgefehler des Shutdowns schieben.
Spanning Tree im Single Span Verfahren mit RSTP und mit Root Priority (z.B. 8192) auf den Cisco Stack hast du auf beiden Switches aktiviert ?! (Loop Prevention)
Wenn Du mit beide den Stack und den Mikrotik Switch meinst - natürlich, alles wie empfohlen, der Cisco-Stack hat die niedridigste Prioität.Grüße
lcer
Zitat von @lcer00:
Die USV hat übrigens versagt, nachdem die Mitarbeiter zum beheben des Piepens im Serverschrank den FI-Schutzschalter ausgeschaltet haben, nachdem der Strom gerade wieder da war. OK Unterdimensioniert. Wobei die Switche keine Shutdownfunktion haben und immer "hart" ausgehen.
Die USV hat übrigens versagt, nachdem die Mitarbeiter zum beheben des Piepens im Serverschrank den FI-Schutzschalter ausgeschaltet haben, nachdem der Strom gerade wieder da war. OK Unterdimensioniert. Wobei die Switche keine Shutdownfunktion haben und immer "hart" ausgehen.
Kurze Nachfrage aus neugier dazu: Wieso versagt die USV wenn ein FI fliegt? Genau das muss Sie doch abfangen?
Zitat von @Ex0r2k16:
Kurze Nachfrage aus neugier dazu: Wieso versagt die USV wenn ein FI fliegt? Genau das muss Sie doch abfangen?
Zitat von @lcer00:
Die USV hat übrigens versagt, nachdem die Mitarbeiter zum beheben des Piepens im Serverschrank den FI-Schutzschalter ausgeschaltet haben, nachdem der Strom gerade wieder da war. OK Unterdimensioniert. Wobei die Switche keine Shutdownfunktion haben und immer "hart" ausgehen.
Die USV hat übrigens versagt, nachdem die Mitarbeiter zum beheben des Piepens im Serverschrank den FI-Schutzschalter ausgeschaltet haben, nachdem der Strom gerade wieder da war. OK Unterdimensioniert. Wobei die Switche keine Shutdownfunktion haben und immer "hart" ausgehen.
Kurze Nachfrage aus neugier dazu: Wieso versagt die USV wenn ein FI fliegt? Genau das muss Sie doch abfangen?
In etwa so (meine wahrscheinlichste Rekonstruktion der Vorgänge):
- Lichtschalter drücken
- Sicherung fliegt raus
- Mitarbeiter geht zum Sicherungskasten, mach Sicherung rein und FI vom Serverschrank (separater Stromkreis) raus * warum auch immer
- alles piept
- Panik
- nach einigen Minuten hört das Piepen auf weil alle Geräte aus sind (USV am Limit / Akku alle)
Grüße
lcer
der Cisco-Stack hat die niedridigste Prioität.
Du meinst sicher die höchste oder ?? Bei der STP Priorität bedeutet ein kleinerer Wert modulo 4096 eine größere Priorität. Default ist 32678.Zitat von @aqui:
der Cisco-Stack hat die niedridigste Prioität.
Du meinst sicher die höchste oder ?? Bei der STP Priorität bedeutet ein kleinerer Wert modulo 4096 eine größere Priorität. Default ist 32678.4096
Grüße
lcer
👍
Wenns das denn nun war bitte dann auch den Thread als erledigt schliessen !
How can I mark a post as solved?
How can I mark a post as solved?
Zitat von @aqui:
Wenns das denn nun war bitte dann auch den Thread als erledigt schliessen !
How can I mark a post as solved?
Wenns das denn nun war bitte dann auch den Thread als erledigt schliessen !
How can I mark a post as solved?
OK, ich leiste Deinem Wunsch folge. Allerdings weiß ich immer noch nicht was genau passiert ist
Grüße
lcer
