13
Redundante L2 LWL Leitung über 2 Standorte - Spanning Tree - HP Equipment
Hallo,
ich stehe vor der Herausforderung eine Redundante L2 LWL Leitung über 2 Standorte herzustellen. Grundsätzliches Switching Know How ist vorhanden, jedoch habe ich noch nicht mit Spanning Tree gearbeitet, beziehungsweise nur in der Standard Konfiguration die von Werk geliefert wird.
Zum Szenario:
2 Standorte
Identes Equipment (HP Switches)
Edge A1 hat Priority 0
Edge A2 hat Priority 1
Ich hätte jetzt gerne das der Link zwischen Edge A2 und Edge B2 blockiert wird. Nur wenn der Link zwischen Edge A1 und Edge B1 nicht verfügbar ist, soll das Protokoll diesen freigeben.
Ist das irgendwie realisierbar?
Besten Dank
ich stehe vor der Herausforderung eine Redundante L2 LWL Leitung über 2 Standorte herzustellen. Grundsätzliches Switching Know How ist vorhanden, jedoch habe ich noch nicht mit Spanning Tree gearbeitet, beziehungsweise nur in der Standard Konfiguration die von Werk geliefert wird.
Zum Szenario:
2 Standorte
Identes Equipment (HP Switches)
Edge A1 hat Priority 0
Edge A2 hat Priority 1
Ich hätte jetzt gerne das der Link zwischen Edge A2 und Edge B2 blockiert wird. Nur wenn der Link zwischen Edge A1 und Edge B1 nicht verfügbar ist, soll das Protokoll diesen freigeben.
Ist das irgendwie realisierbar?
Besten Dank
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 358071
Url: https://administrator.de/contentid/358071
Printed on: April 25, 2024 at 03:04 o'clock
13 Comments
Latest comment
Hi Resolv,
habe ich bei uns mehrfach so im Einsatz, Switches sind unter anderem HP1910.
Welche HP Hardware ist denn bei dir im Einsatz?
habe ich bei uns mehrfach so im Einsatz, Switches sind unter anderem HP1910.
Welche HP Hardware ist denn bei dir im Einsatz?
Im Lab wo ich gerade sitze und versuche das zu testen sind es 2510G. Ich habe mich jetzt mit den Pfad Kosten etwas gespielt, bedeutet auf Edge A2 und Edge B2 auf den Ports 48 bzw. 24 die Pfadkosten auf 40000 gesetzt. Jetzt Blockiert Edge B2 den Port 24. Eigendlich genau das was ich haben wollte, ich stelle mir nur die Frage Edge A2 ist Backup Root. Warum Blockiert nicht Edge A2 den Port 48?
Ich glaube ich werde wohl den Brocken von HP lesen müssen..
Ich glaube ich werde wohl den Brocken von HP lesen müssen..
Deine Switches kenne ich nicht, was du schreibst kommt mir auf Anhieb auch nicht bekannt vor.
Wenn ich mich richtig erinnere gibt es bei den 1910 Switches auf der Weboberfläche den Punkt MSTP. Dort kann definiert werden, welche Ports Spanning Tree nutzen sollen. Die Switches entscheiden dann selbst, welcher Port als Master und welcher als Slave läuft.
Es war in jedem Fall nicht viel Konfiguration notwendig.
Wenn ich mich richtig erinnere gibt es bei den 1910 Switches auf der Weboberfläche den Punkt MSTP. Dort kann definiert werden, welche Ports Spanning Tree nutzen sollen. Die Switches entscheiden dann selbst, welcher Port als Master und welcher als Slave läuft.
Es war in jedem Fall nicht viel Konfiguration notwendig.
Das ist schon korekt. Ich arbeite lieber mit der Console ist aber Nebensache. STP oder MSTP läuft ja bereits. Ich habe aber das Ziel das die Verbindung Edge A1 mit B1 zu priorisieren ist. Bedeutet, nur wenn diese Verbindung nicht zu Verfügung steht, soll die Verbindung zwischen Edge A2 und B2 aufgehen. Ich möchte nicht das dass STP protokoll entscheidet welche Links es blockiert. Blockiert es mit die Links zwischen Edge B1 und B2, dann habe ich ein Problem da dies sozusagen eine WAN L2 Stecke ist. Die Links zwischen Edge A1 und A2, und die Links zwischen Edge B1 und B2 sollten bestenfalls nie vom STP Blockiert werden
Alles klar, dann weiss ich nun zumindest was du erreichen willst. Kann da im Detail aber leider nicht helfen. Viel erfolg dir
Ich arbeite lieber mit der Console
Sehr vernünftig ! Real networkers do CLI 
Ich möchte nicht das dass STP protokoll entscheidet welche Links es blockiert.
Das ist natürlich völliger Quatsch, denn nur RSTP kann es hier entscheiden. Welches Protokoll sollte es denn auch sonst tun ?? Die HP Billiggurken haben ja nicht viel mehr....aber egal.ich stehe vor der Herausforderung eine Redundante L2 LWL Leitung über 2 Standorte herzustellen.
Das ist keine wirkliche Herausforderung sondern in 10 Minuten erledigt ! jedoch habe ich noch nicht mit Spanning Tree gearbeitet,
Das ist in dem obigen Design dann aber Pflicht !Edge A1 hat Priority 0
Völlig falsche Priorities ! Jeder Netzwerker lernt in der Netzwerk Grundschule das STP Priorities immer Modulo 4096 konfiguriert werden müssen !Warum das so ist zeigt dir dieses Diagramm der BPDU Bridge Priority Codierung im Frame:
Fazit: Stelle es so ein das am Standort A der Switch A1 Root Switch ist mit der Priority 4096 und der Switch A2 Backup Root ist mit der Priority 8192
Die beiden Switches im Standort B belässt du auf dem Default !
Dann stellt sich genau das Verhalten ein was du skizziert hast.
Niemals frickelt man hier mit den einzelnen Pfad Kosten rum, das ist kontraproduktiv im STP !
Du nutzt dafür IMMER die globale Bridge Priority !
Das obige Design ist eigentlich STP Steinzeit und hat einen gravierenden Nachteil:
Warum ??
Die Backup LWL Leitung ist durch RSTP tot und dümpelt nur rum um zu warten das die primäre Leitung ausfällt. Was nie oder nur extrem selten der Fall ist.
Bei so teuren LWL Resourcen zwischen 2 Gebäuden ist das höcht ineffizient und kein Netzwerker macht heutzutage noch so ein steinzeitliches Design um solche (Bandbreiten) Resourcen sinnlos zu verschwenden bzw. ungenutzt zu lassen !! In Zeiten steigender Bandbreitenanforderungen wäre das auch fahrlässig.
Dazu gäbe es 2 mögliche einfache Lösungsszenarien:
1.)
Wenn mehrere VLANs im Spiel sind benutzt man MSTP als STP Protokoll und nutzt 2 Instanzen z.B. in denen man die eine und die andere Hälfte der VLANs plaziert.
Die eine Instanz wird dann über LWL 1 priorisiert und die andere Instanz über LWL 2. Natürlich mit gegenseitigem Backup.
So verteilt man sinnvoll die Last des Traffics auf beide LWL Leitungen und nutzt diese aktiv inklusive Failover.
2.)
Hat man die entsprechende Hardware die ein LAG Splitting (sog. vLAG oder MLAG) supportet auf 2 physische Switches kann man über beide LWL Leitungen einen LAG (Link Aggregation) nach Standard 802.3ad mit LACP etablieren.
Damit hätte man dann eine Hash basierte Verteilung des gesamten Traffics mit Failover und könnte auf die Spanning Tree Frickelei komplett verzichten.
Features sind z.B. Virtual Port Channel, vPC (Cisco), Multi Chassis Trunking, MCT (Brocade), usw.
Ob deine HP Billiggurken das supporten steht im Handbuch. (Können die Procurve Billigteile aber wohl eher nicht)
DAS wäre dann eine sinnvolle Option die 2te Leitung auch aktiv zu nutzen. MST supporten auch die HP Gurken so das du Option 1 immer umsetzen kannst.
Dieser Thread beschreibt dir wie man das mit der MSTP Lösung 1.) auf HP Teilen schnell und einfach umsetzt:
Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)
Spanning Tree ist kein Hexenwerk, man muss es nur sinnvoll einzusetzen wissen und nicht Rumfrickeln nach Trial and Error Methode wie es oben leider den Anschein hat.
Zitat von @aqui:
Spanning Tree ist kein Hexenwerk, man muss es nur sinnvoll einzusetzen wissen und nicht Rumfrickeln nach Trial and Error Methode wie es oben leider den Anschein hat.
Spanning Tree ist kein Hexenwerk, man muss es nur sinnvoll einzusetzen wissen und nicht Rumfrickeln nach Trial and Error Methode wie es oben leider den Anschein hat.
Vollkommen korrekt. Aus diesem Grund habe ich mich hier ja gemeldet. Nur vorab, Konfiguriere ich das klassische STP am Switch ohne die Pfad-Kosten zu ändern, Blockt er mir immer am Standort B die Ports 45 zwischen Edge B1 und B2. Genau das brauche ich nicht. Wie gesagt sitze ich hier im LAB und das ist nicht die Realität. Kann schon sein das er die Kosten der Leitungen in der Realität dann anders berechnet.
Active - Active klingt gut. Sollte ich in betracht ziehen, jedoch habe ich dafür im Moment keine Verwendung da es sich hierbei rein um den (WAN) Bereich handelt. Da hängen nur Firewalls drauf, kein Endgerät. Unser tatsächliches Ziel ist es eigendlich 2 Standorte in L2 miteinander zu verbinden und auf dieser L2 Stecke einen IPSEC tunnel zu fahren. Jeglicher Traffic geht über den IPSEC Tunnel. Daher haben ich aktuell noch nicht die Anforderung Active-Active bzw. müsste ich mir da dann auch den Kopf darüber zerbrechen, wie ich das mit dem Tunnel anstelle. Eventuell 2 Tunnel und den Traffic dann auf der Firewall in den entsprechenden Tunnel Routen.
Mit MSTP habe ich mich gestern auch schon beschäftigt und etwas gelesen. Leider ist es da mit 1-2 Stunden nicht getan. Ich habe eine weitere Instanz angelegt und da ein VLAN draufgepackt. Sobald ich aber einen Config-Name vergebe, pfeift er auf meine gesetzt Pfad-Kosten. Wir wird wohl nix anderes überbleiben als mich einzulesen. Im STP Bereich habe ich leider absolut keine Erfahrung.
Das mit den Prio´s habe ich verstanden. Bei HP 0-15, daher 1= 4096 , 2= 8192
Ich prüfe das alles mal und melde mich dann nochmals.
Aqui,
@Resolv hat zwei Standorte. Aktuell ist es so, dass der rot markierte Link geblockt wird. Sein Ziel ist aber, dass der grün markierte Link geblockt wird.
Warum wird im Moment der rote Link geblockt und was muss er tun, um sein Ziel zu erreichen?
@Resolv hat zwei Standorte. Aktuell ist es so, dass der rot markierte Link geblockt wird. Sein Ziel ist aber, dass der grün markierte Link geblockt wird.
Stopp! Ich habe bereits MSTP umgesetzt, schicke euch in den nächsten Stunden ein Update wie ich das jetzt konfiguriert habe und noch ein paar Fragen dazu.
Nur vorab, Konfiguriere ich das klassische STP am Switch ohne die Pfad-Kosten zu ändern
Erstens solltest du immer RSTP nehmen heutzutage und nicht mehr das uralte Spanning Tree. Zweitens hast du recht, denn wenn du gar nichts machst kaspern sich die 4 Switches selber aus wer Root und Backup Root Switch ist, deshalb bekommst du auch unvorhergesehene Blocking Ports. Logisch....Fehlt die Definition der Bridge Priority, dann zählt die Mac Adresse des Switches. Der niedrigste gewinnt und wird Root.
Das wird auch nicht besser oder anders wenn du uns das 2mal schilderst
Setze also die Root Priority entsprechend und Backup Root und dann kommt das auch zum Fliegen und lasse die Frickelei mit den Pfad Kosten.
Um den grünen Pfad in den Blocking Mode zu bringen musst du die Switches so einstellen:
Switch A1 = Bridge Priority 4096
Switch B1 = Bridge Priority 8192
Dann stellt sich genau das Verhalten ein !
Auch bei Billigheimer HP sofern die sich Standard konform verhalten (was sie auch ganz sicher tun!)
Wie gesagt es löst aber nicht den Nachteil das der Backup Link dann tot und ungenutzt ist.
Das bekommst du nur mit einem Instanzen Balancing und MSTP hin wie es oben in Option 1 beschrieben ist.
Option 2 fällt aus weil deine Billigswitches das nicht können bzw. supporten.
Das Thema hat sich vorerst erledigt. Wir werden das versuchen mittels dem HP Distributed Trunk Protokoll zu lösen. Hierfür werden wir neue Hardware anschaffen da die bestehende dies nicht unterstützt.
Trotzdem Danke für eure Unterstützung und den Input. Einiges davon hat mir die Augen geöffnet. Leider sind wir im Switching Bereicht sehr HP lastig, hätte auch lieber gerne Cisco im Haus.
Trotzdem Danke für eure Unterstützung und den Input. Einiges davon hat mir die Augen geöffnet. Leider sind wir im Switching Bereicht sehr HP lastig, hätte auch lieber gerne Cisco im Haus.
Igitt und dann übles HP Geraffel. Nimm doch wenigstens dann mal Netzwerk Hardware die den Namen auch verdient. Und nicht das was ein PC und Druckerhersteller als OEM Ware verkauft !
Außer Cisco gibts ja noch andere die das besser können.
Und....
Cisco hat mit der SoHo Serie SG-500 auch solche Komponenten die das supporten und die preislich genau das HP Niveau haben aber von der Performance und Featureset Welten von den HP Gurken entfernt sind.
Aber letztlich deine Entscheidung. Jeder bekommt halt die Infrastruktur die er verdient.
Außer Cisco gibts ja noch andere die das besser können.
Und....
Cisco hat mit der SoHo Serie SG-500 auch solche Komponenten die das supporten und die preislich genau das HP Niveau haben aber von der Performance und Featureset Welten von den HP Gurken entfernt sind.
Aber letztlich deine Entscheidung. Jeder bekommt halt die Infrastruktur die er verdient.
Zitat von @Resolv:
Das Thema hat sich vorerst erledigt. Wir werden das versuchen mittels dem HP Distributed Trunk Protokoll zu lösen. Hierfür werden wir neue Hardware anschaffen da die bestehende dies nicht unterstützt.
Das Thema hat sich vorerst erledigt. Wir werden das versuchen mittels dem HP Distributed Trunk Protokoll zu lösen. Hierfür werden wir neue Hardware anschaffen da die bestehende dies nicht unterstützt.
Warum die Krücke Distributed Trunking? Wenn Ihr schon neue Switche beschafft, dann nehmt doch solche, die sich als sog. virtuelles Chassis stacken lassen. Wenn es unbedingt HP bzw. Aruba sein muss: seit dem Aufkauf von H3C ist diese Technik auch hier verfügbar - zumindest in den ComWare-basierenden Switchen (Feature: IRF). Möglicherweise ist diese Technik mittlerweile auch in ArubaOS integriert worden - da musst Du Dich mal beraten lassen, so genau kenne ich mich damit leider nicht aus.
Gruß
sk
