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
Please also mark the comments that contributed to the solution of the article
Content-ID: 668566
Url: https://administrator.de/contentid/668566
Printed on: November 13, 2024 at 11:11 o'clock
9 Comments
Latest comment
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.
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.
Allerdings habe ich auf den Cisco-Switches bisher noch kein Routing konfiguriert
Da hilft dann, wie immer, Tutorial lesen wie z.B. HIER!