Netzwerkkonfiguration - Knoten im Kopf

Ein Paar mehr Infos wären schon nicht schlecht:

- sind die M4300 als Stack konfiguriert oder stand alone?

- Soll das "Fallback" auf L2 oder L3 erfolgen?

- die Switche stehen in unterschiedlichen Gebäuden? Du weißt schon, das man da LWL nimmt und nicht Cu (Potentialverschleppung --> Beschädigung, Brandgefahr)!

Jürgen

Hi

wenn das alles Switche sind, dann hast einen sauberen Loop , da muss entweder was abschalten oder STP korrekt einrichten und die PathCost so anpassen, dass der die bessere Leitung immer "online" hält und den anderen Link an einer bestimmten Stellen "kappt".

Alternative: Ringprotokoll (kenne jetzt nur MRP von Ruckus), aber das werden die Wahrscheinlich nicht können.

Gruß
@clSchak

@clSchak den Loop-Fehler macht man nur einmal in einem produktiven Netzwerk, das garantiere ich dir *haha*

Klar, STP ist hier ein Muss, wenn man die Switche nicht im Stack hat.

Spanning Tree mit RSTP auf allen Switches aktivieren und dem Hauptswitch (Root Switch, wo Router Server usw. angeschlossen sind) immer eine höhere STP Priority geben z.B. 8192 (müssen immer Vielfache von 4096 sein!)
Damit ist das dann auch problemlos in einem flachen L2 Netzwerk machbar.
Ist ja ne simple Leitungsredundanz im Layer 2 und Spanning Tree sorgt dafür das es zu keinem Loop kommt, da nur die Root Switch Links im Forwarding Mode sind.

Ringstrukturen sind im Ethernet was in der Regel Sterndesigns erfordert generell immer kritisch aber da du nur max. 2 Hops hast ist das tolerabel. Bei 3 oder mehr Hops ist das in der Regel ein NoGo und man sollte dann immer entsprechende Ringprotokolle verwenden wie Kollege @clSchak schon richtig sagt.

Deine "Klimmzüge" sind etwas unverständlich. Im Grunde ist das doch ein primitives RSTP Failover in einem Dreieck wo du alle 3 Switches mit dem 10-2000er Trunk verbindest. Der 3te Link am unteren Switch ist irgendwie unverständlich und auch nutzlos.
Die Netgear Gurken können eh nur Single Spann Verfahren, also reicht es die globale RSTP Prio der Switches zu setzen um Root und Backup Root Switch und damit die Root Ports zu bestimmen.
Da wo der Stern ist geht deine Leitung in den RSTP Blocking Mode damit es nicht zu einem Loop kommt. Im Fehlerfalle der anderen Links oder Switches wird das RSTP Blocking aufgehoben.
Eigentlich doch ganz simpel. 🤔

Es bleibt dabei... Parallele Links bedeuten ja immer einen Loop und je nach STP Priority geht ein Link davon in den Blocking Mode.
Ports müssen keinesfalls in Priority konfiguriert werden, das macht die Sache nur unnötig kompliziert. Es reicht wenn man das global macht.
Aus Netzwerksicht hast du ja nichts anderes als 2 parallele Links und musst auch nichts machen wenn beide gleich konfiguriert sind.

Der große Nachteil ist bei einem solchen Layer 2 Design das von den 2 Links die man teuer bezahlt immer nur einer aktiv ist und der andere frisst nur ungenutzt Geld für nichts anstatt aktiv zur Bandbreitenerhöhung genutzt zu werden weil er nur im Blocking wartet das der erste ausfällt.
Sowas ist generell schlecht da ineffizient als Layer 2 Design auszulegen. Switching über eine Funkverbindung so oder so weil man dort teure Bandbreite unnütz mit Broad- und Multicast Traffic belastet.
Deutlich besser und effizenter wäre ein L3 Design was dann ein aktives Balancing macht über beide Links.

Was aber nun doch wieder verwirrend ist ist das nach deiner Skizze es nun doch keine parallelen Links gibt sondern beide Cores einzug nur mit dem RiFu Link verbunden ist. 🤔
Damit wäre die ganze Diskussion dann obsolet?!

Na ja, so hätte man virtuelle 400Mbit. Per se ja nicht schlecht.
Solche Rahmenbedingungen erzwingen dann aber förmlich ein Layer 3 Design in so einer Anbindung und sollte des immer primäre Lösung sein. Wie man dann auf die Idee kommt sowas dann dennoch in Layer 2 zu machen ist schwer nachvollziehbar. Aber ok, ist ja auch primär nicht das Thema hier...
Das ist technisch mit deinen Hardware Voraussetzungen nur mit PVSTP in einem Layer 2 Design möglich. Stellt sich die Frage wie du das genau versucht hast zu bewerkstelligen?
Man kann das in L2 nur machen wenn man VLANs nutzt und PVSTP aktiv hat. (Per VLAN Spanning Tree).
Damit hätte man eine individuelle STP Instanz pro einzelnem VLAN und könnte dann mit den STP Priorities jonglieren, das der eine Link die VLANs bedient und der andere die anderen VLANs. Das wäre ein klassisches und sicheres Verfahren, bedeutet aber das dein Spanning Tree Verfahren durchgängig auf PVRSTP oder MSTP umgestellt werden müsste, sofern diese denn überhaupt MSTP supporten? PVRSTP oder PVRSTP+ supporten die NG Gurken m.W. gar nicht.
Den MSTP Instances gibt man dann unterschiedliche Prios und gut ist. Damit verteilt man die Layer 2 Last auf mehrere Links mit gegenseitigem Failover.
Aber mal zurück zum eigentlichen Thema:

Versteht man dich jetzt richtig geht es nur um den parallelen Link einmal vom Stack direkt auf das RF60 RiFu Device und einmal vom Stack via Switch UV-A auf das RiFu Device.
In dem Design ist ja davon auszugehen das der Link Stack-UV-A und auch UV-A auf das RiFu Device vom L2 Tagging völlig identisch konfiguriert ist wie der direkte Link Stack-RiFu. Muss ja auch so sein wenn das ein Backup sein soll.
Switchtechnisch gesehen ist das dann natürlich ein Loop wie man dann unschwer erkennen kann, was der STP aber löst mit entsprechendem Blocking. Soviel zur Theorie...

Nun stellt sich aber die Frage ob das RiFu Device aktiv am Spanning Tree teilnimmt, sprich also aktiv STP macht mit den anderen Switch Komponenten??
Sollte das der Fall sein, geht der Link von UV-A am RiFu Device in den Blocking State. Logisch denn wenn der Stack Root Switch ist und damit eine höhere RSTP Prio hat als der UV-A Switch ist durch den zusätzlichen Hop die STP Cost schlechter.
Soweit so gut.... Könnte man alles so lassen und hat dann über den 2ten Link über UV-A eine Backup Verbindung wenn der direkte Link vom Stack zum RiFu Device gestört ist.
Das wäre dann doch eigentlich genau das was du willst, oder?

Wenn allerdings das RiFu Device jetzt nicht aktiv am Spanning Tree teilnimmt, kommt es darauf an ob es BPDU Frames einfach durchschleift oder diese blockiert. Dazu hast du leider nichts gesagt und diese Info fehlt und das würde das STP Verhalten dann entsprechend anders beeinflussen.

Im Grunde ist das sofern das RiFu Device am STP aktiv teilnimmt (und in gewissen Grenzen auch wenn es "nur" durchschleift) ein simples und klassisches Standard STP Verhalten. Wo siehst du denn da noch irgendwelche Probleme?