
Wir haben einen flachen Büronetzwerkbaum, der auf einer Reihe verschiedener ProCurve L2- und L3-GigE-Switches basiert und sich über rund 300 Ports erstreckt. Heute habe ich festgestellt, dass eines der Geräte im Netzwerk für einen kurzen Zeitraum übermäßige Übertragungen verursacht, die die meisten 100-MBit/s-Verbindungen überlasten und bestimmte Dienste wie VoIP beeinträchtigen. Das Gerät ist mit dem ProCurve 3500yl-Switch verbunden, der der Root-Switch des Netzwerks ist, und daher breitet sich der Sturm über den Root-Switch auf das restliche Netzwerk aus.
Q:Gibt es eine Möglichkeit, das Problem zu lokalisieren und zu verhindern, dass der Sturm über den Root-Switch schwappt?
Hier sind einige weitere Einzelheiten zu meinem Fall, die relevant sein könnten, da ich möglicherweise eine falsche Frage stelle und die beste Lösung woanders liegen könnte.
Das Gerät, das den Sturm verursacht, ist selbst ein ProCurve 3400cl (J4905A) PoE-Switch mit einer veralteten Firmware-Version M.10.76
aus dem Jahr 2009.Ich weiß, es ist alt, werde am Wochenende das Neueste flashen.
Der 3400cl ist an eine Stromquelle angeschlossen, die zeitweise längere Ausfälle hat. Wenn die Stromversorgung nach einem Ausfall wiederhergestellt ist, benötigt das Gerät etwa 5 Minuten zum Booten. Zu diesem Zeitpunkt fließt der Datenverkehr durch das Gerät, während das Gerät und seine Verbindungen noch nicht vollständig eingerichtet sind. Während dieser Zeit spuckt es alle möglichen Arten von unerwünschtem Datenverkehr in das Netzwerk, der schwer zu erfassen ist, aber in den über SNMP erfassten Statistiken Spitzenwerte hinterlässt.
Während dieser Zeit sehe ich High collision or drop rate. See help.
Nachrichten auf vielen 100-MBit/s-Ports im Netzwerk.
Der 3400cl ist über zwei physische GigE-Verbindungen mit dem 3500yl verbunden. Der 3400cl verwendet RSTP, während der 3500yl mit dem Spanning Tree Protocol MSTP konfiguriert ist. Während des Normalbetriebs wird eine der Verbindungen durch RSTP auf dem 3400cl deaktiviert, während die andere weiterleitet.
Wenn 3400cl neu startet, kann ich die folgenden Meldungen in den Protokollen von 3500yl sehen
14:05:03 ... port 37 is now off-line
14:05:04 ... port 38 is now off-line
14:05:51 ... port 37 is blocked by STP
14:05:51 ... port 38 is blocked by STP
14:05:54 ... port 37 is now on-line
14:05:54 ... port 38 is now on-line
und dann sehe ich High collision or drop rate
100-MBit/s-Ports, die mit 3500yl verbunden sind, und die Switches auf niedrigerer Ebene, die damit verbunden sind.
14:07:11 ... port NN-High collision or drop rate. See help.
Auch die VoIP-Benutzer erleben Unterbrechungen.
Die einzige sofortige Maßnahme, die ich versuchen konnte, war, broadcast-limit 5
das 3500yl-Portpaar einzubauen. Ich bin mir nicht sicher und konnte nicht testen, ob es helfen wird. Außerdem fühlt es sich sehr an wie einad hocLösung.