9
RSTP vs. Loopback-Erkennung
Hallo in die Runde,
ich würde hier bitte wieder etwas Unterstützung für mein privates Netz benötigen.
Wie auf dem Bild zu sehen, ist der Großteil meines Netzes in Gebäude A. Um Gebäude B an das Netz anzubinden existieren zwei MikroTik WLAN Bridges an je einen Cisco SG300 Switch in diesem Gebäude. Seit mehren Jahren waren die beiden bzw. drei Cisco Switches mit einem Link verbunden, so dass es einen Loop geben könnte. Allerdings ist RSTP aktiviert und die Pfadkosten so eingestellt, dass genau der markierte Link nicht aktiv war.
Dieser Aufbau hatte den Vorteil, dass bei einer Unterbrechnung einer WLAN-Bridge (z.B. während eines Firmwareupdate) das komplette Netz weiter funktionierte.
Heute habe ich nun ein Firmwareupdate für die WLAN-Bridge von 7.14 auf 7.16 installiert. Als das WLAN auf der Bridge wieder hoch kam, fing das Netz an zu "spinnen". Ständig wurde die Loopback-Erkennung ausgelöst.
Ist es normal, dass die Loopback-Erkennung schneller als das RSTP ist?
Muss Loopback auf allen beteiligten Ports deaktiviert werden?
Kann ich das RSTP irgendwie "beschleunigen"?
Ich verstehe nicht, warum es nun nach dem Firmwareupdate auf der einen Bridge nicht mehr funktioniert, da auf beiden Bridges RSTP und Loopback-Erkennung deaktiviert sind.
Ich habe nun erst mal den Link zwischen den Switches deaktiviert, somit funktioniert alles wieder. Dies hat aber den Nachteil, dass sich das Netz im Falle des Ausfalls einer WLAN-Bridge, nicht mehr "selbstheilt".
Ich hoffe, dass ich keine wesentlichen Infos vergessen habe.
Viele Grüße und einen schönen Feiertag
Alex
ich würde hier bitte wieder etwas Unterstützung für mein privates Netz benötigen.
Wie auf dem Bild zu sehen, ist der Großteil meines Netzes in Gebäude A. Um Gebäude B an das Netz anzubinden existieren zwei MikroTik WLAN Bridges an je einen Cisco SG300 Switch in diesem Gebäude. Seit mehren Jahren waren die beiden bzw. drei Cisco Switches mit einem Link verbunden, so dass es einen Loop geben könnte. Allerdings ist RSTP aktiviert und die Pfadkosten so eingestellt, dass genau der markierte Link nicht aktiv war.
Dieser Aufbau hatte den Vorteil, dass bei einer Unterbrechnung einer WLAN-Bridge (z.B. während eines Firmwareupdate) das komplette Netz weiter funktionierte.
Heute habe ich nun ein Firmwareupdate für die WLAN-Bridge von 7.14 auf 7.16 installiert. Als das WLAN auf der Bridge wieder hoch kam, fing das Netz an zu "spinnen". Ständig wurde die Loopback-Erkennung ausgelöst.
Ist es normal, dass die Loopback-Erkennung schneller als das RSTP ist?
Muss Loopback auf allen beteiligten Ports deaktiviert werden?
Kann ich das RSTP irgendwie "beschleunigen"?
Ich verstehe nicht, warum es nun nach dem Firmwareupdate auf der einen Bridge nicht mehr funktioniert, da auf beiden Bridges RSTP und Loopback-Erkennung deaktiviert sind.
Ich habe nun erst mal den Link zwischen den Switches deaktiviert, somit funktioniert alles wieder. Dies hat aber den Nachteil, dass sich das Netz im Falle des Ausfalls einer WLAN-Bridge, nicht mehr "selbstheilt".
Ich hoffe, dass ich keine wesentlichen Infos vergessen habe.
Viele Grüße und einen schönen Feiertag
Alex
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: 668566
Url: https://administrator.de/forum/rstp-vs-loopback-erkennung-668566.html
Ausgedruckt am: 22.12.2024 um 03:12 Uhr
9 Kommentare
Neuester Kommentar
Hast Du die Logs noch? Wenn ja bitte Posten, dann kann man nachvollziehen, was passiert war.
So kann man nur die Theorie runter spulen und es ist voraus gesetzt, dass Du die verstanden hast?
So kann man nur die Theorie runter spulen und es ist voraus gesetzt, dass Du die verstanden hast?
Grundsätzlich habe ich die Logs noch. Aus meiner Sicht steht da aber nichts interessantes drin.
Vor dem Cisco-175 hängt mein zentraler "Haupt"-Switch Cisco-172. Deshab habe ich das Bild nochmal beigefügt
Dieser Switch ist mit Port 21 mit dem Cisco-175 verbunden. Auf Port 21 war allerdings die Loopback-Erkennung nicht deaktiviert. Daher hat er den Port einfach zu gemacht und das gesammt hier dargestellte Netz (links vom Cisco-172) war tot.
Ich bin nur Hobby-Admin meines eigenen Netzes, wahrscheinlich fehlt mir ja ein Teil der Theorie.
Deshalb die Frage muss die Loopback-Erkennung auf den RSTP-Ports deaktiviert werden, weil sie schneller als RSTP ist? Allerdings hat es ja ein paar Jahre funktioniert???
Vor dem Cisco-175 hängt mein zentraler "Haupt"-Switch Cisco-172. Deshab habe ich das Bild nochmal beigefügt
Dieser Switch ist mit Port 21 mit dem Cisco-175 verbunden. Auf Port 21 war allerdings die Loopback-Erkennung nicht deaktiviert. Daher hat er den Port einfach zu gemacht und das gesammt hier dargestellte Netz (links vom Cisco-172) war tot.
Ich bin nur Hobby-Admin meines eigenen Netzes, wahrscheinlich fehlt mir ja ein Teil der Theorie.
Deshalb die Frage muss die Loopback-Erkennung auf den RSTP-Ports deaktiviert werden, weil sie schneller als RSTP ist? Allerdings hat es ja ein paar Jahre funktioniert???
Normalerweise willst du entweder Loopback-Erkennung ODER Spanning-Tree auf solchen Ports. Denn wenn die Loopback-Detection was erkennt, frisst sie die STP-BPDUs und damit weiß Spanning-Tree nicht, dass da ein redundanter Weg ist und setzt den Port entsprechend nicht auf Blocking.
Zudem will man eigentlich das STP auf allen beteiligten Geräten machen – denn wenn die WLAN-Bridge selbst auch Spanning-Tree macht, kann sie den Link-Zustand der WLAN-Verbindung berücksichtigen, was die Switches dahinter nicht können. So kann es dir passieren, dass du bei Wiederkehr der WLAN-Verbindung für einige Sekunden einen Loop hast, bis der Switch wieder ein BPDU empfängt und den Port blocken kann.
Zudem will man eigentlich das STP auf allen beteiligten Geräten machen – denn wenn die WLAN-Bridge selbst auch Spanning-Tree macht, kann sie den Link-Zustand der WLAN-Verbindung berücksichtigen, was die Switches dahinter nicht können. So kann es dir passieren, dass du bei Wiederkehr der WLAN-Verbindung für einige Sekunden einen Loop hast, bis der Switch wieder ein BPDU empfängt und den Port blocken kann.
2
Die Logs der Mikrotik-Geräte, Da sollten auch Mac-Adressen zu sehen sein, damit man nachvollziehen kann, warum der Baum sich geschüttelt hat.
...vielen Dank für Eure Hinweise!!
Ja, auch auf der WLAN-Bridge wurden Loops gesehen.
Also wenn ich das richtig verstehe, muss ich auf allen Ports, die den Ring auf dem Bild darstellen Loopback-Erkennung deaktivieren und RSTP aktivieren.
Ich werde es testen und gebe Bescheid!!
Ja, auch auf der WLAN-Bridge wurden Loops gesehen.
Also wenn ich das richtig verstehe, muss ich auf allen Ports, die den Ring auf dem Bild darstellen Loopback-Erkennung deaktivieren und RSTP aktivieren.
Ich werde es testen und gebe Bescheid!!
Super!!!
Es hat tatsächlich funktioniert!!
Ich habe auf den beiden WLAN-Bridges auf beiden Seiten Loopback-Erkennung deaktiviert und auch hier RSTP eingeschalten.
Jetzt konnte ich den Link zwischen dem Cisco-143 und Cisco-144 ohne Problem wieder auf aktiv setzen und der Switch hat ihn automatisch als "Alternativ" im RSTP markiert.
Vielen Dank!!
Viele Grüße
Alex
Es hat tatsächlich funktioniert!!
Ich habe auf den beiden WLAN-Bridges auf beiden Seiten Loopback-Erkennung deaktiviert und auch hier RSTP eingeschalten.
Jetzt konnte ich den Link zwischen dem Cisco-143 und Cisco-144 ohne Problem wieder auf aktiv setzen und der Switch hat ihn automatisch als "Alternativ" im RSTP markiert.
Vielen Dank!!
Viele Grüße
Alex
und RSTP aktivieren.
Wenn man RSTP aktiviert MUSS das durchgängig auf allen Infrastruktur Komponenten passieren! Sinnvollerweise bestimmt man mit dem Root Switch und Backup Root Switch über die Priority die beiden STP Root Kandidaten. (Siehe dazu auch hier und auch hier)Dieser Aufbau hatte den Vorteil,
Nur nebenbei...Das Design hat 2 gravierende Nachteile:
- Die Kopplung beider Gebäude ist flach, basiert also auf einem simplen Layer 2 Bridging. Das bedeutet das die Funkbrücke mit ihrer prinzipbedingten deutlich schwächeren Bandbreite zusätzlich noch unnötigerweise mit dem gesamten Broad- und Multicast Traffic beider Gebäudenetze beeintrachtigt wird, was die Performance noch weiter sinken lässt. Bei einer funkbasierten Kopplung sollte man wenn es irgend geht immer routen und niemals bridgen. Jeder kennt das goldene Admin Sprichwort "Route where you can, bridge where you must". Zumal routingfähige L3 Switches im Einsatz sind wäre es deutlich sinnvoller gewesen die Gebäudenetze zu trennen und über die L3 Switches zu routen wie z.B. HIER ansatzweise beschrieben.
- Durch das flac he Design und dem daraus resultierenden Spanning Tree Blocking eines Links bleibt dieser Link produktiv immer tot und wird nicht sinnvoll genutzt! Das ist sehr ineffizient wenn man teueres Equipment dafür beschafft hat. Auch hier wäre ein Routing deutlich sinnvoller, denn damit wäre der parallele Betrieb beider Funkbrücken möglich MIT Load Balancing bei gleichzeitigem Failover.
@ aqui
Vielen Dank für Deine zusätzlichen HInweise!
Das Sprichwort kenne ich mittlerweile nun auch schon. Allerdings habe ich auf den Cisco-Switches bisher noch kein Routing konfiguriert, bisher habe ich es nur auf MikroTik gemacht. Habe ich mir aber als nächstes mal vorgenommen!
Neben ein paar Netzwerkkameras hängen in dem Gebäude B nur eins, zwei Clients zum Internet surfen – bisher gab es hier noch keine Geschwindkeitsprobleme, zumal ich eh nur ein DSL100 habe. Die 100MBit bleiben bei den beiden 1GBit-Links der WLAN’s wahrscheinlich immer übrig.
Weiterhin habe ich das RSTP über die Pfadkkosten so konfiguriert, dass immer der Link zwischen den Switches und nicht das WLAN tot liegt. Somit teilen sich die Kameras die beiden WLAN-Links auf (ein paar an dem Switch und ein paar an dem anderen).
Mit etwas mehr Erfahrung stelle ich es eventuell nochmal um – nochmal vielen Dank und
Viele Grüße
Alex
Vielen Dank für Deine zusätzlichen HInweise!
Das Sprichwort kenne ich mittlerweile nun auch schon. Allerdings habe ich auf den Cisco-Switches bisher noch kein Routing konfiguriert, bisher habe ich es nur auf MikroTik gemacht. Habe ich mir aber als nächstes mal vorgenommen!
Neben ein paar Netzwerkkameras hängen in dem Gebäude B nur eins, zwei Clients zum Internet surfen – bisher gab es hier noch keine Geschwindkeitsprobleme, zumal ich eh nur ein DSL100 habe. Die 100MBit bleiben bei den beiden 1GBit-Links der WLAN’s wahrscheinlich immer übrig.
Weiterhin habe ich das RSTP über die Pfadkkosten so konfiguriert, dass immer der Link zwischen den Switches und nicht das WLAN tot liegt. Somit teilen sich die Kameras die beiden WLAN-Links auf (ein paar an dem Switch und ein paar an dem anderen).
Mit etwas mehr Erfahrung stelle ich es eventuell nochmal um – nochmal vielen Dank und
Viele Grüße
Alex
Allerdings habe ich auf den Cisco-Switches bisher noch kein Routing konfiguriert
Da hilft dann, wie immer, Tutorial lesen wie z.B. HIER! 
