STP bei nicht-redundantem Switch-Netzwerk
Hallo zusammen,
folgende Frage beschäftigt mich seit ein paar Stunden:
Im Zuge einer neuen Telefonanlage (VoIP - Serverbasiert) und dessen Implementierung sind wir auf Netzwerk-Performance-Probleme gestoßen.
Für genauere Untersuchungen hab ich mit Wireshark und Port-Mirroring die Pakete ausgelesen und konnte STP-Probleme (Bad Checksums - CMC => 0x0000000, should be xxxxxxxxxxx) in Zusammenhang mit unserer Root-Bridge feststellen.
Unsere Netzwerk-Topologie ist sternförmig. In der Mitte nutzen wir einen Switch als Backbone, von dem aus jeweils EINE Verbindung zu einem anderem Switch (z.B. in einem anerem Stockwerk) führt. Alle Switche und WLAN-Access-Points laufen daher nicht redundant zum Backbone-Switch. Meines Wissens nach bräuchte man hier nicht mal STP, da dieses Protokoll nur dazu verwendet wird, Loops bei Mehrweg-Verbindungen zu verhindern. Jetzt weiß aber, dass einer der Kollegen vor 1-2 Jahren STP verwendet hatte, da einer der Windows-Clients 2 NICs gekoppelt hatte (WLAN und LAN), beide im Netz hingen und somit eine Loop geschaffen hatte, welche das Netzwerk lahm gelegt hatte...
Meine Frage an der Stelle ist, ob der STP-Fehler nicht sogar vielleicht deswegen auftritt, da unter normalen Umständen (keine Multipath-Ways, wenn nicht einer der Kollegen wieder mit seinem Windows-Client rumspielt) garkeine redundanten Verbindungen zu anderen Netzwerk-Geräten existieren?
Wäresuper dankbar, wenn hier jemand eine Idee hat und diese posten könnte..
Viele Grüße und einen schönen Feierabend,
Havokx23
folgende Frage beschäftigt mich seit ein paar Stunden:
Im Zuge einer neuen Telefonanlage (VoIP - Serverbasiert) und dessen Implementierung sind wir auf Netzwerk-Performance-Probleme gestoßen.
Für genauere Untersuchungen hab ich mit Wireshark und Port-Mirroring die Pakete ausgelesen und konnte STP-Probleme (Bad Checksums - CMC => 0x0000000, should be xxxxxxxxxxx) in Zusammenhang mit unserer Root-Bridge feststellen.
Unsere Netzwerk-Topologie ist sternförmig. In der Mitte nutzen wir einen Switch als Backbone, von dem aus jeweils EINE Verbindung zu einem anderem Switch (z.B. in einem anerem Stockwerk) führt. Alle Switche und WLAN-Access-Points laufen daher nicht redundant zum Backbone-Switch. Meines Wissens nach bräuchte man hier nicht mal STP, da dieses Protokoll nur dazu verwendet wird, Loops bei Mehrweg-Verbindungen zu verhindern. Jetzt weiß aber, dass einer der Kollegen vor 1-2 Jahren STP verwendet hatte, da einer der Windows-Clients 2 NICs gekoppelt hatte (WLAN und LAN), beide im Netz hingen und somit eine Loop geschaffen hatte, welche das Netzwerk lahm gelegt hatte...
Meine Frage an der Stelle ist, ob der STP-Fehler nicht sogar vielleicht deswegen auftritt, da unter normalen Umständen (keine Multipath-Ways, wenn nicht einer der Kollegen wieder mit seinem Windows-Client rumspielt) garkeine redundanten Verbindungen zu anderen Netzwerk-Geräten existieren?
Wäresuper dankbar, wenn hier jemand eine Idee hat und diese posten könnte..
Viele Grüße und einen schönen Feierabend,
Havokx23
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 352725
Url: https://administrator.de/contentid/352725
Ausgedruckt am: 26.11.2024 um 19:11 Uhr
4 Kommentare
Neuester Kommentar
Meines Wissens nach bräuchte man hier nicht mal STP
Oberflächlich ja aber das ist nur oberflächlich gedacht. Es übersieht Mitarbeiter die aus versehen mal einen Loop stecken oder selber mitgebrachte Tischswitches aus Versehen (oder auch mit Vorsatz) loopen lassen. Ohne Spanning Tree ist sowas tödlich in einem Netzwerk im wahrsten Sinne des Wortes.Aus dem Grunde sollte man immer Spanning Tree und auch Loop Protection aktivieren. Ein sauberes STP Design mit Root Switch und Backup Root natürlich vorausgesetzt.
Ausnahme ist wenn man modernere Stacking basierte Designs verwendet und mit LACP LAGs arbeitet oder ein Fabric basiertes netzdesign auf TRILL oder SPB Basis.
Aber auch dann sollte man zum Edge aus Sicherheit immer STP aktivieren, mindestens aber Loop Protection.
Macht man das nicht droht latent immer der Netzwerk Tod.
Loops bei Mehrweg-Verbindungen zu verhindern
Nein, das ist natürlich Quatsch. Das verhindert logischerweise auch Loops am gleichen Switch. Nicht aber Loops am gleichen Port (gleiche STP BPDU Pakete am gleichen Port). Bei Letzterem greift nur Loop Protection.dass einer der Kollegen vor 1-2 Jahren STP verwendet hatte, da einer der Windows-Clients 2 NICs gekoppelt hatte und somit eine Loop geschaffen hatte, welche das Netzwerk lahm gelegt hatte...
Der Klassiker ! Was deinen Fehler anbetrifft ist das doch kein struktureller Fehler im RSTP an sich. Das sagt doch schon die Fehlermeldung an sich ! Dort ist die Layer 2 Checksumme des Packetes defekt oder falsch.
Das heisst das Paket an sich hat schon gravierende Bitfehler auf dem untersten Layer die in einer falschen Checksumme resultieren und damit das Paket als ungültig deklarieren. Der Switch verwirft es deshalb.
Also der fehler liegt schon in der Bitstruktur der Signalisierung selber. Vom STP und dessen Auswertung ist es damit logischerweise noch meilenweit entfernt.
Solche Fehler sind sehr häufig der Grund bei fehlerhafter Verkabelung also defekten Steckern, Kabel und optischen Transceivern.
Möglich und auch sehr wahrscheinlich wäre auch ein Firmware Bug oder defekte Hardware eines beteiligten Switches !
Hier solltest du dringenst prüfen ob die Switches alle auf die aktuellste Firmware geflasht sind. Die Dell Power Connects sind billigste Taiwan Switches die bei Accton in Taiwan als Massenware zusammengekloppt werden. Dell OEMt die nur und bäppelt da nur sein Logo drauf. Es ist deshalb nicht auszuschliessen das einer dieser Billigteile auch ein physisches Problem hat, also defekt oder teildefekt ist.
Dazu müsste man genau den Port analysieren der diese Pakete mit den fehlerhaften Prüfsummen generiert. Genau da ist der Fehler.
Solche kaputten BPDU Frames sind natürlich tödlich für den STP (besser RSTP) Prozess, denn der Switch dropt in der Regel diese Frames und wertet sie aktiv nicht aus. Mit der Folge das der Spanning Tree dann nicht zuverlässig läuft mit den möglichen Auswirkungen von oben.
Das solltest du also dringenst fixen.
Moin,
zum Thema STP ist ja schon alles ausführlich gesagt worden
Aber deinem Performance Problemen wirst du imo mit Wireshark nicht auf die Schliche kommen... Da solltest du als erstes mal die korrekte Switch Konfig Prüfen (Voice VLAN, QoS usw) und dir dann mal die Werte (CRCs/Drops) der Ports ansehen.
lg,
Slainte
zum Thema STP ist ja schon alles ausführlich gesagt worden
Aber deinem Performance Problemen wirst du imo mit Wireshark nicht auf die Schliche kommen... Da solltest du als erstes mal die korrekte Switch Konfig Prüfen (Voice VLAN, QoS usw) und dir dann mal die Werte (CRCs/Drops) der Ports ansehen.
lg,
Slainte