4
SFP+ 10GBit (Kupfer) + RSTP führt zu Problem
Hallo,
wir testen gerade die redundante Anbindung einer Verteilung mittels RSTP:
Die Verteilung ist bis jetzt einzig über Kupfer (1x 10GBit) angebunden, was einwandfrei funktioniert, keinerlei Fehler auf dem Link!
Nun soll aus Redundanzgründen noch eine 1GBit Kupfer Leitung dazugenommen werden und über RSTP betrieben werden.
Dies funktioniert augenscheinlich auch, in der (vom der Root-Bridge weiter entfernten) Verteilung geht der 1GBit Kupferport auf Staus "Blocked", der 10GBit SFP+ Kupferport auf "Forward".
Leider kommt es trotzdem zu einem komischen Verhalten, das Netz wird extrem träge, Geräte reagieren teilweise nicht mehr und der Broadcast-Traffic nimmt extrem zu. Das würde alles auf einen Loop deuten, was aber nicht sein kann, da ein Port ja im Stauts "Blocked" ist?! Zieht man ein Kabel ab, ob disabled einen Port (des imaginären Loops) über den Switch, läuft wieder alles normal.
Kann das ein Problem mit dem SFP+ Modulen sein? Diese sind von FS.com und nicht vom Switchhersteller selbst.
Das Modul taucht im Switch auch als "Ethernet Compliance Code: 10G Base-SR" auf. Es müsste jedoch eigentlich "10G Base-T" stehen...
Hat jemand etwas ähnliches beobachtet?
Vielleicht in einem vergleichbaren Setup: 10GBit Kuper (SFP+) + 1GBit Kupfer in Verbindung mit RSTP?
Danke
wir testen gerade die redundante Anbindung einer Verteilung mittels RSTP:
Die Verteilung ist bis jetzt einzig über Kupfer (1x 10GBit) angebunden, was einwandfrei funktioniert, keinerlei Fehler auf dem Link!
Nun soll aus Redundanzgründen noch eine 1GBit Kupfer Leitung dazugenommen werden und über RSTP betrieben werden.
Dies funktioniert augenscheinlich auch, in der (vom der Root-Bridge weiter entfernten) Verteilung geht der 1GBit Kupferport auf Staus "Blocked", der 10GBit SFP+ Kupferport auf "Forward".
Leider kommt es trotzdem zu einem komischen Verhalten, das Netz wird extrem träge, Geräte reagieren teilweise nicht mehr und der Broadcast-Traffic nimmt extrem zu. Das würde alles auf einen Loop deuten, was aber nicht sein kann, da ein Port ja im Stauts "Blocked" ist?! Zieht man ein Kabel ab, ob disabled einen Port (des imaginären Loops) über den Switch, läuft wieder alles normal.
Kann das ein Problem mit dem SFP+ Modulen sein? Diese sind von FS.com und nicht vom Switchhersteller selbst.
Das Modul taucht im Switch auch als "Ethernet Compliance Code: 10G Base-SR" auf. Es müsste jedoch eigentlich "10G Base-T" stehen...
Hat jemand etwas ähnliches beobachtet?
Vielleicht in einem vergleichbaren Setup: 10GBit Kuper (SFP+) + 1GBit Kupfer in Verbindung mit RSTP?
Danke
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 592047
Url: https://administrator.de/contentid/592047
Ausgedruckt am: 21.11.2024 um 17:11 Uhr
4 Kommentare
Neuester Kommentar
Hi,
wenn man bedenkt, dass STP ein reines Schutzprotokoll ist, du es hier aber "misshandelst" für andere Zwecke, kann allerlei passieren.
Bau dir lieber einen vernünftigen Portchannel, dann klappt das auch (was auch immer du für Switches hast).
wenn man bedenkt, dass STP ein reines Schutzprotokoll ist, du es hier aber "misshandelst" für andere Zwecke, kann allerlei passieren.
Bau dir lieber einen vernünftigen Portchannel, dann klappt das auch (was auch immer du für Switches hast).
Moin..
ok.. mit was für Geräten?
Die Verteilung ist bis jetzt einzig über Kupfer (1x 10GBit) angebunden, was einwandfrei funktioniert, keinerlei Fehler auf dem Link!
Nun soll aus Redundanzgründen noch eine 1GBit Kupfer Leitung dazugenommen werden und über RSTP betrieben werden.
ok
Dies funktioniert augenscheinlich auch, in der (vom der Root-Bridge weiter entfernten) Verteilung geht der 1GBit Kupferport auf Staus "Blocked", der 10GBit SFP+ Kupferport auf "Forward".
Bitte was... du meinst doch sicher 10G-T SFP+ mit RJ45... oder..?
zeichne uns doch mal auf, wie deine verdrahtung sein soll... bitte mit geräte bezeichnungen
Leider kommt es trotzdem zu einem komischen Verhalten, das Netz wird extrem träge, Geräte reagieren teilweise nicht mehr und der Broadcast-Traffic nimmt extrem zu. Das würde alles auf einen Loop deuten, was aber nicht sein kann, da ein Port ja im Stauts "Blocked" ist?! Zieht man ein Kabel ab, ob disabled einen Port (des imaginären Loops) über den Switch, läuft wieder alles normal.
hm...
Kann das ein Problem mit dem SFP+ Modulen sein? Diese sind von FS.com und nicht vom Switchhersteller selbst.
Das Modul taucht im Switch auch als "Ethernet Compliance Code: 10G Base-SR" auf. Es müsste jedoch eigentlich "10G Base-T" stehen...
Hat jemand etwas ähnliches beobachtet?
Vielleicht in einem vergleichbaren Setup: 10GBit Kuper (SFP+) + 1GBit Kupfer in Verbindung mit RSTP?
ich verstehe nich so ganz, was du mit Setup: 10GBit Kuper (SFP+) + 1GBit Kupfer meinst...
Danke
Frank
ok.. mit was für Geräten?
Die Verteilung ist bis jetzt einzig über Kupfer (1x 10GBit) angebunden, was einwandfrei funktioniert, keinerlei Fehler auf dem Link!
Nun soll aus Redundanzgründen noch eine 1GBit Kupfer Leitung dazugenommen werden und über RSTP betrieben werden.
Dies funktioniert augenscheinlich auch, in der (vom der Root-Bridge weiter entfernten) Verteilung geht der 1GBit Kupferport auf Staus "Blocked", der 10GBit SFP+ Kupferport auf "Forward".
zeichne uns doch mal auf, wie deine verdrahtung sein soll... bitte mit geräte bezeichnungen
Leider kommt es trotzdem zu einem komischen Verhalten, das Netz wird extrem träge, Geräte reagieren teilweise nicht mehr und der Broadcast-Traffic nimmt extrem zu. Das würde alles auf einen Loop deuten, was aber nicht sein kann, da ein Port ja im Stauts "Blocked" ist?! Zieht man ein Kabel ab, ob disabled einen Port (des imaginären Loops) über den Switch, läuft wieder alles normal.
Kann das ein Problem mit dem SFP+ Modulen sein? Diese sind von FS.com und nicht vom Switchhersteller selbst.
Das Modul taucht im Switch auch als "Ethernet Compliance Code: 10G Base-SR" auf. Es müsste jedoch eigentlich "10G Base-T" stehen...
Hat jemand etwas ähnliches beobachtet?
Vielleicht in einem vergleichbaren Setup: 10GBit Kuper (SFP+) + 1GBit Kupfer in Verbindung mit RSTP?
Danke
Das ist meines Erachtens ein total simples, reduandantes Design.
(R)STP wir hier auch keinesfalls "misshandelt", das ist genau der Anwendungsfall für den man STP nutzt!
Hier das Bild, Kardinalsfrage, warum entsteht hier ein Loop, obwohl ein Port in dem STP-Verbund auf Blocked geht??
Die genutzten 10GBase-T-SFP+-Module: https://www.fs.com/de/products/89579.html
Klar wäre eine LAG schöner, aber ich habe keinen 10GBit-Port dort mehr frei und die finanzielle Lage (wegen Corona) lässt auch keine Neuanschaffung in diesem Unternehmen zu.
(R)STP wir hier auch keinesfalls "misshandelt", das ist genau der Anwendungsfall für den man STP nutzt!
Hier das Bild, Kardinalsfrage, warum entsteht hier ein Loop, obwohl ein Port in dem STP-Verbund auf Blocked geht??
Die genutzten 10GBase-T-SFP+-Module: https://www.fs.com/de/products/89579.html
Klar wäre eine LAG schöner, aber ich habe keinen 10GBit-Port dort mehr frei und die finanzielle Lage (wegen Corona) lässt auch keine Neuanschaffung in diesem Unternehmen zu.
wenn man bedenkt, dass STP ein reines Schutzprotokoll ist, du es hier aber "misshandelst" für andere Zwecke
Sorry, aber das ist schlicht falsch. Das ist aus RSTP Sicht ein absolut sauberes und übliches Design. "Missbraucht" wie du es fälschlicherweise ausdrückst wird hier keineswegs etwas. In jedem Stanning Tree aktiven netzwerk kann man redundnate Links unterschiedlicher Speed ziehen, das ist normal und absolut legitim !Der 1 GiG Link sollte im RSTP Tree aufgrund seiner schlechteren Port Cost immer in den Blocking Mode am der Root Bridge entferntesten Punkt gehen.
Das ist absoluter RSTP Standard und völlig normal im Spanning Tree.
Um Die Kardinalsfrage zu beantworten brauchen wir aber ein paar mehr wichtige Details:
- Gibt es aus den 2 D-Links noch andere Switches im Netz die RSTP sprechen. Wenn ja sollten ausnahmslos ALLE für RSTP Im Single Span Verfahren konfiguriert sein !
- Wenn es noch andere Switches gibt, nutzen die ggf. ein per VLAN RSTP Verfahren wie PVRSTP oder PVRSTP+ (Cisco). Diese Verfahren sind nicht kompatibel zum einfachen Single Span RSTP der D-Link Gurken und das führt dann zu solchen Symptomen.
- Welcher Switch ist der Root Switch und auf welchen Wert ist der gesetzt ? Bedenke RSTP Prio Werte müssen immer modulo 4096 angegeben werden. Wichtig ist auch das die Prio Switch bezogen konfiguriert ist und nicht Port bezogen !
- Beide Switches sollten eine identische und wenn immer möglich die aktuellste Firmware Version konfiguriert haben !
An den Modulen selber liegt es nicht. Ist ja auch klar, denn das ist reine Physik die nur dafür sorgt das die Signale auf den Draht kommen. Die können doch niemals als vollkommen passive Komponenten in aktive Protokolle eingreifen. Wie sollte das gehen ?
Hätten sie einen Fehler würdest du nicht einmal einen aktiven Netzwerk Link bekommen !
Ein Punkt gäbe es da aber...
Die meisten Switches erzwingen auf SFP+ Ports eine dedizierte und statische Speed Angabe in der Konfig, weil es eben im LWL Bereich kein Autosensing gibt wie man es bei Kupfer gewöhnt ist. Es ist also sehr gut möglich das du dem Port eine statische Speed mitgeben musst damit dieser fehlerlos funktioniert.
