7
Mikrotik RSTP Problem
Hallo zusammen,
ich habe das Problem, dass der Uplink Port meines Switches ACS1 ständig zwischen up und down flackert, allerdings in unregelmäßigen Abständen. Ich habe keine Idee mehr, woran es liegen kann. Hardwarefehler ist ausgeschlossen und es wird die Version 1.17.1 von RouterOS auf allen Switchen ausgeführt. Folgendes Schema zeigt, wie die Verkabelung der Switche ist:
Meine Bridge Prioritäten und Path-Costs sind wie folgt:
DIST1
bridge priority: 6000hex
Path Cost sfp28-1: 2
Path Cost sfp-sfpplus1: 10
Path Cost sfp-sfpplus2: 10
DIST2
bridge priority: 8000hex
Path Cost sfp-sfpplus1: 20
Path Cost sfp-sfpplus2: 20
ACS1
bridge priority: e059hex
Path Cost sfp-sfpplus1: 10
Path Cost sfp-sfpplus2: 20
ACS2
bridge priority: e059hex
Path Cost sfp-sfpplus1: 10
Path Cost sfp-sfpplus2: 20
DIST2 hat noch keinen Uplink, da die neuen redundanten CORE Switche noch folgen. Beide ACS bedienen gleichzeitig Clients. Vielleicht hat jemand auf Anhieb eine Idee, was die Ursache sein könnte.
Zusätzliche Info: Sobald ich den DIST2 ausschalte, läuft es sauber.
Danke schonmal!
ich habe das Problem, dass der Uplink Port meines Switches ACS1 ständig zwischen up und down flackert, allerdings in unregelmäßigen Abständen. Ich habe keine Idee mehr, woran es liegen kann. Hardwarefehler ist ausgeschlossen und es wird die Version 1.17.1 von RouterOS auf allen Switchen ausgeführt. Folgendes Schema zeigt, wie die Verkabelung der Switche ist:
Meine Bridge Prioritäten und Path-Costs sind wie folgt:
DIST1
bridge priority: 6000hex
Path Cost sfp28-1: 2
Path Cost sfp-sfpplus1: 10
Path Cost sfp-sfpplus2: 10
DIST2
bridge priority: 8000hex
Path Cost sfp-sfpplus1: 20
Path Cost sfp-sfpplus2: 20
ACS1
bridge priority: e059hex
Path Cost sfp-sfpplus1: 10
Path Cost sfp-sfpplus2: 20
ACS2
bridge priority: e059hex
Path Cost sfp-sfpplus1: 10
Path Cost sfp-sfpplus2: 20
DIST2 hat noch keinen Uplink, da die neuen redundanten CORE Switche noch folgen. Beide ACS bedienen gleichzeitig Clients. Vielleicht hat jemand auf Anhieb eine Idee, was die Ursache sein könnte.
Zusätzliche Info: Sobald ich den DIST2 ausschalte, läuft es sauber.
Danke schonmal!
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 671126
Url: https://administrator.de/forum/mikrotik-rstp-problem-671126.html
Ausgedruckt am: 12.03.2025 um 11:03 Uhr
7 Kommentare
Neuester Kommentar
hex e059 = 57433 ist nicht RSTP konform, da STP Bridge Priorities prinzipbedingt immer Vielfache von 4096 sein müssen! (Siehe u.a. auch hier)
Es reicht vollständig die globale Root Bridge Priority zu setzen und die des Backup Root Switches. An den Pfad Kosten muss und sollte man niemals fummeln.
Bei dir also z.B. DIST1 = 8192 (0x2000) und DIST2 = 12288 (0x3000)
Die Priority aller restlichen Switches belässt man immer auf dem Default 32768 (0x8000) denn die STP Topologie wird durch die beiden priorisierten Root Switches damit fest vorgegeben!
Das solltest du korrigieren, Pfad Kosten auf Default dann klappt das auch.
Boot Loader unter System --> Routerboard auch auf diese Version (hoffentlich 7.17.1) korrekt upgedatet?
Es reicht vollständig die globale Root Bridge Priority zu setzen und die des Backup Root Switches. An den Pfad Kosten muss und sollte man niemals fummeln.
Bei dir also z.B. DIST1 = 8192 (0x2000) und DIST2 = 12288 (0x3000)
Die Priority aller restlichen Switches belässt man immer auf dem Default 32768 (0x8000) denn die STP Topologie wird durch die beiden priorisierten Root Switches damit fest vorgegeben!
Das solltest du korrigieren, Pfad Kosten auf Default dann klappt das auch.
die Version 1.17.1 von RouterOS auf allen Switchen
1.17.1 ??? Bist du dir da sicher? Die Version ist falsch. 🤔Boot Loader unter System --> Routerboard auch auf diese Version (hoffentlich 7.17.1) korrekt upgedatet?
Wenn es das denn nun war bitte deinen Thread dann auch als erledigt schliessen!
Wie kann ich einen Beitrag als gelöst markieren?
Wie kann ich einen Beitrag als gelöst markieren?
Hallo aqui,
Danke für deinen Input.
Ich hatte mich bei der Einstellung hex e059 = 57433 vertan, es muss 57344 sein.
Leider hat es das Problem aber noch nicht gelöst.
Und ja ich meinte natürlich die RouterOS Version 7.17.1 (mittlerweile bin ich auf 7.17.2).
Habe einen Beitrag im Mikrotik Forum gefunden, welcher sich mit derselben Problematik befasst.
https://forum.mikrotik.com/viewtopic.php?t=141633
Habe aufgrund dessen mal den Port mit einem DAC Kabel ausgestattet, dort funktioniert es nun, aber jetzt flippert Port 2. Man sieht in den Mikrotik Stats, dass der Connector Type immer von LC zu unknown wechselt.
Habe ehrlich gesagt nicht die Absicht nun alles mit DAC-Kabeln zu verbinden :D
Danke für deinen Input.
Ich hatte mich bei der Einstellung hex e059 = 57433 vertan, es muss 57344 sein.
Leider hat es das Problem aber noch nicht gelöst.
Und ja ich meinte natürlich die RouterOS Version 7.17.1 (mittlerweile bin ich auf 7.17.2).
Habe einen Beitrag im Mikrotik Forum gefunden, welcher sich mit derselben Problematik befasst.
https://forum.mikrotik.com/viewtopic.php?t=141633
Habe aufgrund dessen mal den Port mit einem DAC Kabel ausgestattet, dort funktioniert es nun, aber jetzt flippert Port 2. Man sieht in den Mikrotik Stats, dass der Connector Type immer von LC zu unknown wechselt.
Habe ehrlich gesagt nicht die Absicht nun alles mit DAC-Kabeln zu verbinden :D
Ich hatte mich bei der Einstellung hex e059 = 57433 vertan, es muss 57344 sein.
Das ist so oder so überflüssiger Unsinn, denn es reicht vollkommen Root und Backup Root Switch zu definieren. Den Rest belässt man immer auf dem Default 32768.Durch die eindeutige Festlegung von Root und Backup Root sind ALLE Root Ports und damit die Forwarding Topologie für den Rest der Switches immer fest vorgegeben. Es wäre also überflüssig (und auch ziemlich kontraproduktiv) hier noch eine Verschlechterung des Default Wertes zu customizen.
Würde jemand einen billigen Workgroupswitch an diese Switches anstöpseln mit der Default Priority hätte der sofort eine höhere Bridge Priority als die 57344 und kapert deine STP Topologie. Ein NoGo in einem stabilen STP Design und sollte man keinesfalls so lassen!!
Habe aufgrund dessen mal den Port mit einem DAC Kabel ausgestattet, dort funktioniert es nun
Das zeigt ja dann eindeutig das du ein phyisches Problem mit entweder deinen Optiken oder den Kabeln oder beidem hast!dass der Connector Type immer von LC zu unknown wechselt.
Mikrotik macht keinen Vendor Check! Es kann also nicht an einem fehlenden Hersteller Branding liegen weil das keine Rolle spielt.Es sind die Parameter der Optik die nicht lesbar sind für den Switch also ein grundlegender Fehler dieser Optik. Fragt sich was du da eingekauft hast??
Mit Mikrotik gebrandeten FS.COM Optiken machst du nichts falsch und solltest dir zu mindesten einmal 2 Optiken davon beschaffen und die an dem Port testen.
Zu 98% ist der Fehler dann verschwunden!
https://www.fs.com/de/products/230693.html?attribute=71404&id=383481 ...
Nur nebenbei:
Du solltest dir für so ein Setup generell noch einmal überlegen ob STP hier die richtige Strategie ist. Heutzutage ist das etwas Design Steinzeit für so ein Setup mit STP zu arbeiten.
Überlicherweise würde man die beiden Distrubutions Switches in einen MLAG Cluster konfigurieren!
Link Aggregation (LAG) im Netzwerk
https://help.mikrotik.com/docs/spaces/ROS/pages/67633179/Multi-chassis+L ...
Daran bindet man die Access Switches mit einem LACP LAG an.
Damit erreicht man nicht nur einen deutlich schnelleren Failover bei sowohl Core Switch- als auch Linkausfall sondern nutzt auch aktiv ALLE Backbone Uplinks für das Traffic Forwarding, dupliziert also quasi die Bandbreite.
Ein aus Kosten, Redundanz- und Traffic Sicht deutlich besseres und effizienteres Design, weil Links eben nicht passiv brachliegen und auf ein fast nie auftretendes Ausfall Szenario warten wie in einem antiken STP Design, sondern aktiv genutzt werden.
Das ist so oder so überflüssiger Unsinn, denn es reicht vollkommen Root und Backup Root Switch zu definieren. Den Rest belässt man immer auf dem Default 32768.
Durch die eindeutige Festlegung von Root und Backup Root sind ALLE Root Ports für den Rest der Switches fest vorgegeben. Es wäre also überflüssig (und auch ziemlich kontraproduktiv) hier noch eine Verschlechterung des Default Wertes zu customizen.
Würde jemand einen billigen Workgroupswitch an diese Switches anstöpseln mit der Default Priority hätte der sofort eine höhere Bridge Priority als die 57344. Ein NoGo in einem stabilen STP Design und sollte man keinesfalls so lassen!!
Durch die eindeutige Festlegung von Root und Backup Root sind ALLE Root Ports für den Rest der Switches fest vorgegeben. Es wäre also überflüssig (und auch ziemlich kontraproduktiv) hier noch eine Verschlechterung des Default Wertes zu customizen.
Würde jemand einen billigen Workgroupswitch an diese Switches anstöpseln mit der Default Priority hätte der sofort eine höhere Bridge Priority als die 57344. Ein NoGo in einem stabilen STP Design und sollte man keinesfalls so lassen!!
Ja, das ist verstanden und werde ich auch noch ändern, danke für deine Hilfe.
Mikrotik macht keinen Vendor Check! Es kann also nicht an einem fehlenden Hersteller Branding liegen weil das keine Rolle spielt.
Genau das war auch mein Ansatz, ich verwende Generische SFP-10GSR-85 von FS.com
Ich werde noch einige Sachen durchtesten und dann nochmal Feedback geben.
Nur nebenbei:
Du solltest dir für so ein Setup generell noch einmal überlegen ob STP hier die richtige Strategie ist. Heutzutage ist das etwas Design Steinzeit für so ein Setup mit STP zu arbeiten.
Überlicherweise würde man die beiden Distrubutions Switches in einen MLAG Cluster konfigurieren!
Link Aggregation (LAG) im Netzwerk
https://help.mikrotik.com/docs/spaces/ROS/pages/67633179/Multi-chassis+L ...
Daran bindet man die Access Switches mit einem LACP LAG an.
Damit erreicht man nicht nur einen deutlich schnelleren Failover bei sowohl Core Switch- als auch Linkausfall sondern nutzt auch aktiv ALLE Backbone Uplinks für das Traffic Forwarding, dupliziert also quasi die Bandbreite.
Ein aus Kosten, Redundanz- und Traffic Sicht deutlich besseres und effizienteres Design, weil Links eben nicht passiv brachliegen und auf ein fast nie auftretendes Ausfall Szenario warten wie in einem antiken STP Design, sondern aktiv genutzt werden.
Du solltest dir für so ein Setup generell noch einmal überlegen ob STP hier die richtige Strategie ist. Heutzutage ist das etwas Design Steinzeit für so ein Setup mit STP zu arbeiten.
Überlicherweise würde man die beiden Distrubutions Switches in einen MLAG Cluster konfigurieren!
Link Aggregation (LAG) im Netzwerk
https://help.mikrotik.com/docs/spaces/ROS/pages/67633179/Multi-chassis+L ...
Daran bindet man die Access Switches mit einem LACP LAG an.
Damit erreicht man nicht nur einen deutlich schnelleren Failover bei sowohl Core Switch- als auch Linkausfall sondern nutzt auch aktiv ALLE Backbone Uplinks für das Traffic Forwarding, dupliziert also quasi die Bandbreite.
Ein aus Kosten, Redundanz- und Traffic Sicht deutlich besseres und effizienteres Design, weil Links eben nicht passiv brachliegen und auf ein fast nie auftretendes Ausfall Szenario warten wie in einem antiken STP Design, sondern aktiv genutzt werden.
Ja da hast du vollkommen Recht! Aber leider unterstützen die CCR2004-1G-12S+2XS kein MLAG und ich muss mit der Hardware arbeiten die mein Vorgänger mir hinterlassen hat.
Vielen Dank für die Hilfe, @aqui. Es scheint daran zu liegen, dass die SFP Module übersteuern, weil die Verbindung "zu gut" ist. Mit DAC Kabeln konnte ich das Problem lösen.
dass die SFP Module übersteuern
Das kann passieren ist aber sehr selten.Der einfache Trick ist dann das man das LWL Patchkabel einige Windungen auf einen Kugelschreiber oder Objekt ähnlichen Durchmessers aufwickelt um so die Streckendämpfung zu erhöhen.
Klinkt kurios und skurril ist aber ein probates Mittel um das Problem schnell und unkompliziert zu lösen ohne teuere Dämpfungselemente kaufen zu müssen.
Du kannst das Lichtbudget ja immer einfach in der Interface Sicht kontrollieren denn deinen FS Optiken sind ja DOM fähig.
