malawi
Goto Top

Spanning-Tree Modus-Migration (PVST nach MST bei Cisco)

Hallo zusammen,

wir haben eine heterogene Switchlandschaft, bestehend aus Cisco Catalyst- und Lancom-Switches. Auf allen Lancom-Switches ist RSTP konfiguriert und auf allen Cisco-Switches ist PVST konfiguriert. Um hier einen sauberen Mischbetrieb zu gewährleisten, möchten wir am Sonntag migrieren.

Die Lancom-Switches möchte ich auf ihren Einstellungen belassen und bei den Cisco Switches möchte ich von PVST auf MST migrieren, sodass diese dann ihre Abwärtskompatibilität zu RSTP gegenüber der Lancom's nutzen.

Wir möchten für alle VLANs (aktuell weniger als 10 Stück) die gleiche Bridge als Root definieren. Ich möchte dies gleich für alle VLANs durchführen, auch wenn beispielsweise nur VLAN 1 und VLAN 500 im Moment auf dem Switch aktiv ist. Ist dies wie unten konfiguriert möglich oder müssen die VLANs erst alle vorhanden sein, die dort in der Range angegeben werden können?

Jetzt ist meine Frage, wie ich hier am besten vorgehen kann. Erst die Prioritäten der Root- und Backup-Root-Bridge setzen und dann auf allen Cisco-Switches mode mst umstellen?

Zukünftig gewünschte Root-Bridge:
Switch# config t
Switch# spanning-tree vlan 1-4094 priority 4096
Switch# spanning-tree mode mst
Switch# exit

Zukünftig gewünschte Backup-Root-Bridge:
Switch# config t
Switch# spanning-tree vlan 1-4094 priority 8192
Switch# spanning-tree mode mst
Switch# exit

Da mst ja auf RSTP zurückfallen sollte, muss man die VLANs überhaupt angeben wenn eigentlich gar kein MSTP genutzt wird?
Aktuell sind ALLE Switches auf über 32.000 eingestellt.

Jetzt die Frage, ob es bereits beim Setzen der priority einen neuen Baum berechnet? Wenn ich also 11 Switche umstellen muss, sowohl erst die priority ändere als im Anschluss den spanning-tree mode, dann muss der Baum insgesamt 22-mal neu berechnet werden, ist das richtig oder wird der Baum beim Ändern der priority noch nicht neu berechnet?

Was gibt es bei solch einer Umstellung noch zu beachten? (Best practise, Erfahrungswerte?)

Muss ich noch weitere Vorraussetzungen erfüllen?


Wir nutzen folgende Komponenten:

cisco Catalyst 3750G - 48TS - S | 12.2(53)SE1 / C3750-IPBASEK9-M
cisco Catalyst 3750G - 12S - S | 12.2(53)SE1 / C3750-IPBASEK9-M
cisco Catalyst 3750X - 48T - S | 12.2(55)SE3 / C3750E-UNIVERSALK9-M
cisco Catalyst 3560X - 48P - L | 15.0(2)SE5 / C3560E-IPBASEK9-M
cisco Catalyst 2960X-48LPS - L | 15.2(2)E6 / C2960X-UNIVERSALK9-M

LANCOM GS-1224 | 2.05.0000 (22.11.2012)
LANCOM GS-1224P | 2.05.0000 (22.11.2012)
LANCOM GS-2326 | 3.30.0324 (14.09.2017)
LANCOM GS-2310P | 3.30.0324 (14.09.2017)

Wenn noch weitere Infos gebraucht werden, sagt bitte bescheid!

Danke!

Content-Key: 356746

Url: https://administrator.de/contentid/356746

Ausgedruckt am: 19.03.2024 um 02:03 Uhr

Mitglied: brammer
Lösung brammer 01.12.2017 um 10:45:30 Uhr
Goto Top
Hallo,

hier erst mal der Link auf den MST config guide von Cisco.

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst2960/software ...

Etwas Problematisch sehe ich die Kombination aus Lancom und Cisco ... wobei mir die Cisco keine Sorgen machen....

Wie ist denn die Vemischung der Switche innerhalb des Netzes?
Hast du die Lancom nur als Edge Ports? Und die Cisco als Backbone?
Oder ist der Aufbau buntgemischt?

brammer
Mitglied: brammer
Lösung brammer 01.12.2017 um 10:50:28 Uhr
Goto Top
Hallo,

Jetzt die Frage, ob es bereits beim Setzen der priority einen neuen Baum berechnet? Wenn ich also 11 Switche umstellen muss, sowohl erst die
priority ändere als im Anschluss den spanning-tree mode, dann muss der Baum insgesamt 22-mal neu berechnet werden, ist das richtig oder wird
der Baum beim Ändern der priority noch nicht neu berechnet?

Wenn die Switche mit der neuen Priorität im Netz auftauchen und feststellen das sie nicht die Root Bridge sind wird auch kein Baum neuberechnet, zumindest nicht in der Form das es auf 22 mal eien neue Root Bridge geben wird...
Wenn du zerst die Root bridge konfigurierst und dannach die anderen Switche sollte das kein Problem darstellen ....
Bei deinem Konstrukt wird es erst interessant wenn die Root Bridge weg fällt .... dann wird der Tree neu berechnet. Evtl. solltest du eine Secondary Root Bridge konfigurieren am besten die beiden stärksten Switche also die 3750er....

brammer
Mitglied: aqui
Lösung aqui 01.12.2017 aktualisiert um 12:42:23 Uhr
Goto Top
Auf allen Lancom-Switches ist RSTP konfiguriert und auf allen Cisco-Switches ist PVST konfiguriert.
Das würde dann so auch in die Hose gehen, da beide STP Verfahren NICHT kompatibel sind ! Cisco nutzt zudem eine andere BPDU Mac Adresse die die meisten der einfachen Hersteller wie z.B. deine Lancoms nicht verstehen und somit inkompatibel sind. Einge Hersteller supporten es und customizen die Ports dann entsprechend. Das sind aber Hersteller die generell auch PVSTP bzw. PVSTP+ supporten. Lancom gehört natürlich nicht dazu.
Die Lancom-Switches möchte ich auf ihren Einstellungen belassen und bei den Cisco Switches möchte ich von PVST auf MST migrieren.
Das ist auch der einzig richtige Weg. Lancom Billigswitches supporten wie üblich nur ein reines Single Span Verfahren also ein globaler STP Prozess für alle VLANs.
Das Problem was bei einer reinen Migration nur der Cisco Switches auf MSTP passiert ist das du wieder einen Bruch der Protokolle hast. MSTP nutzt zwar RSTP und ist auch an den reinen Single Span RSTP Port rückwärts kompatibel aber es besteht immer die Gefahr das diese Autoerkennung in billigen Consumer Switches nicht richtig implementiert ist. Hier solltest du wenn du es wirklich durchziehst detailierte Failover Tests VOR dem Produktivbetrieb machen und das auch die Priority Steuerung sauber klappt.

Technisch besser wäre es durchgängig MSTP zu fahren sofern die Lancoms das supporten was sie eigentlich sollten. So hast du ein durchgängiges einheitliches STP Protokoll und verlierst auch nicht die Priorisierung über die unterschiedlichen Instances sofern du sowas bei Mehrfach VLAN Betreibs anstrebst.
Da solltest du nochmal gründlich drüber nachdenken !
Sehr wichtig ist das du den beiden Core Switches zwingend eine höhere STP Priorität statisch gibst damit der STP Baum nicht zufällig errechnet wird aus den Bridge Mac Adressen !
Der Priority Wert von Root und Backup Root Switch sollte modulo 4096 gesetzt sein (Obere 4 Bit der Bridge ID) !
Der Default Prio Wert von 32768 ist Standard ! (Alle oberen 4 Bits der Bridge ID gesetzt). 0 ist verboten !
Also Root Prio 4096 und Backup Root dann Prio 8192. Den Rest der Switches lässt man auf dem o.a. Default. Damit ist der STP Tree sauber vorgegeben.
stp
Ein sehr gutes Dokument zum Thema MSTP Design findest du hier:
http://blog.ine.com/2010/02/22/understanding-mstp/

Deine Konfig Beispiele für die Catalysten oben sind falsch ! Die gelten für PVSTP+ und nicht für MSTP. Das kannst du also vergessen. MSTP ist aber ähnlich.
Die Vorgehensweise von dir ist richtig. Erst die Root und Backup Root Switches und der Prios definieren, die aktivieren and dann Schritt für Schritt die anderen Switches dazuhängen. 4-5 Sekunden "rumpeln" wird es durch den Topo Change etwas wenn neue Switches dazukommen, aber das ist vollkommen normal.
Solltest du trotz der Warnung oben dennoch mit Mischbetrieb MSTP und RSTP fahren wollen, solltest du zuallererst das MSTP Netz der Ciscos sauber definieren und laufen lassen und erst dann die Lancom Gurken anflanschen.
Wie gesagt...besser ist diese AUCH im MSTP Betrieb zu fahren !!

Hier als Beispiel hier mal eine laufende Cisco Konfiguration zweier Core Catalyste mit 3 VLANs in 2 MSTP Instances und einem entsprechenden Load Sharing von redundanten Uplinks.
VLAN 12 (in Instance 2) Ports am Sw 1 gehen in Forwarding (Prio 4096) und die VLANs 1 und 11 (Instance 0 und 1) gehen in Blocking (Prio 8192)
Bei SW2 ist es genau andersrum so das es zu einer optimalen Ausnutzung aller redundanten Links kommt mit einem sinnvollen Load Sharing und gleichzeitigem Backup !

Switch_1#
!
spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
name kevische_netz
revision 1
instance 1 vlan 11
instance 2 vlan 12
!
spanning-tree mst 0-1 priority 8192
spanning-tree mst 2 priority 4096
!

Switch_2#
!
spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
name kevische_netz
revision 1
instance 1 vlan 11
instance 2 vlan 12
!
spanning-tree mst 0-1 priority 4096
spanning-tree mst 2 priority 8192
!
interface Port-channel1
switchport mode trunk
switchport nonegotiate
!

Auf den Ciscos wie immer kein Hexenwerk und mit ein paar IOS Kommandos erledigt. face-wink
Bei Lancom gehts vermutlich via Klicki Bunti GUI, oder ?
Aktuelle Firmware auf den Lancoms ist dringend anzuraten. Bei Cisco sind alle STP Derivate schon seit langem stabil im IOS.
Mit dem o.a. Rüstzeug sollte die Migration dann eine Lachnummer sein face-wink
Mitglied: malawi
malawi 01.12.2017 um 17:54:39 Uhr
Goto Top
Vielen Dank euch beiden für die Mühe.

Hier erstmal ein Bild des logischen Netzaufbaus. Der Netzaufbau ist sicherlich nicht optimal, jedoch ist dies der aktuelle Zustand und da muss ich eben die Migration auf MST hinbekommen. Alle schwarzen Leitungen sind einzelne 1Gbit Uplinks. Die Coreswitche stehen jeweils in einem Serverraum.

2017-12-01 17_29_56-neu0.graphml - yed

Ich habe mich nun etwas belesen und bin zu folgendem gekommen:

Ich würde alle Cisco-Switches einzeln anfassen und folgendes konfigurieren:

Root-Bridge (Core1):
Switch# conf t
Switch(config)# spanning tree mst configuration
Switch(config-mst)# name kevische_netz
Switch(config-mst)# revision 1
Switch(config-mst)# exit
Switch(config)# spanning-tree extend system-id
Switch(config)# spanning-tree mst 0 priority 4096
Switch(config)# spanning-tree mode mst
Switch(config)# exit

Backup-Root-Bridge (Core2):
Switch# conf t
Switch(config)# spanning tree mst configuration
Switch(config-mst)# name kevische_netz
Switch(config-mst)# revision 1
Switch(config-mst)# exit
Switch(config)# spanning-tree extend system-id
Switch(config)# spanning-tree mst 0 priority 8192
Switch(config)# spanning-tree mode mst
Switch(config)# exit

Alle anderen Cisco-Switches:
Switch# conf t
Switch(config)# spanning tree mst configuration
Switch(config-mst)# name kevische_netz
Switch(config-mst)# revision 1
Switch(config-mst)# exit
Switch(config)# spanning-tree extend system-id
Switch(config)# spanning-tree mode mst
Switch(config)# exit

Ich nehme also die Instanz 0, in der default alle VLANs enthalten sind, da ich alle Switches in einer Instanz haben möchte. Jetzt die Frage, ob ich auch auf allen Uplinks der Switche, alle VLANs erlauben muss? Weil ja alle VLANs in Instanz 0 enthalten sind. Ich wollte dies eigentlich eingrenzen, um weniger Traffic über die Uplinks zu generieren.

Ich kann nicht auf allen Lancoms MSTP einstellen, da die älteren 1224er das nicht unterstützen. Bei Cisco kann ich ja lediglich auf MST stellen, was ja abwärtskompatibel zu RSTP ist.

Meine Trunkports sind alle so konfiguriert, auch die Etherchannel Ports:
Switch(config-if)# switchport mode trunk
Switch(config-if)# switchport nonegotiate

Ist die Reihenfolge so ok? Gibts noch was zu verbessern vom Ansatz her?

Danke
Mitglied: malawi
malawi 04.12.2017 um 08:48:05 Uhr
Goto Top
U P D A T E

Gestern habe ich nun versucht, von PVST auf MST umzustellen. Begonnen habe ich damit, dass ich auf allen Cisco-Switches zunächst die MST-Configuration definiert habe. Da hat sich auch noch nichts geändert, war also wie gedacht.

Dann habe ich den Core1 auf MST mit
Switch(config)# spanning-tree mode mst
umgestellt. Den Ping den ich auf das Gerät habe laufen lassen, ist dann abgebrochen und auch nach Minuten nicht mehr hochgekommen. Also gut, starten wir das Gerät neu und probieren das gleiche noch einmal, da dieser Switch in der Vergangenheut schon öfters gezickt hatte. Aber auch beim zweiten Versuch, hat es nicht geklappt. Dann war meine Idee, zunächst auf Rapid-PVST umzustellen, um von dort dann auf MST zu gehen (weil ich irgendwo in den Dokumenten gelesen habe, das MST eher zu Rapid-PVST kompatibel ist, als MST zu PVST).

Also gedacht, getan und siehe da, es funktioniert. Alle weiteren Cisco-Switches die ich danach auf Rapid-PVST umgestellt habe, waren 1-2 Sekunden down und dann wieder erreichbar. Auch bei den Lancoms wurde automatisch vom alten STP auf RSTP an den entsprechenden Uplink-Ports zu den Ciscos umgestellt.

Heute morgen habe ich gelesen, dass meine neue Konstellation, also der Mischbetrieb (Rapid-PVST und MST), nur in VLAN 1 gewährleistet ist.

Eigentlich war ja geplant, nach der Umstellung auf Rapid-PVST anschließend auf MST umzustellen, was ich aber erstmal gelassen habe.

Vielleicht kann hier nochmal jemand ein paar Zeilen schreiben.

Danke für die Unterstützung!
Mitglied: aqui
Lösung aqui 04.12.2017, aktualisiert am 07.06.2021 um 17:59:19 Uhr
Goto Top
Der Netzaufbau ist sicherlich nicht optimal,
In der Tat ! Extreme Bauchschmerzen bereiten diese beiden Ringe ! Sowas ist immer absolut tödlich für ein Spanning Tree Protokoll und allgemein für ein Ethernet Design was primär immer eine Baumstruktur ist.
So bis max. 3 Switches wäre noch tolerabel aber 5 ist sehr schlecht und kann gravierende Nachteile bergen.
Da solltest du über ein Redesign nachdenken um diese Ringe wegzubekommen.
Mindestens aber solltest du auf ein spezielles Ringprotokoll gehen was die meisten Hersteller anbieten. Cisco z.B. mit Resilient Ring oder REP. Das ist optimniert auf Ring Strukturen und eliminiert alle gravierenden Nachteile die STP Protokolle in so einem Umfeld haben.
Ich würde alle Cisco-Switches einzeln anfassen und folgendes konfigurieren:
Kurz vorweg gefragt: Du willst rein nur mit der Default Instnz 0 arbeiten ??
Keinerlei Aufteilung der VLAN in weitere Instanzen oder wenigstens in 2 Instanzen um später, wenn mal Redundanz ein Thema ist oder wird, ein Load Sharing über redundante Links zu machen ?
Erst wenn du diese Frage klar mit Nein (=keine Instance Aufteilung) beantworten kannst, kannst du bei der Default Instanz 0 bleiben.
Sonst solltest du wenigstens 2 Instanzen vorsehen und die VLANs auf diese 2 Instanzen verteilen auch wenn du erstmal mit gleicher Prio in beiden Instanzen arbeitest.

Soweit sind die Konfigs der 3 Core Systeme sauber und richtig mit einer kleinen Ausnahme:
Der Core 3 gehört in diesem Design auch dediziert mit zu den 3 Core Switches und im Anbetracht der recht unglücklichen Ringkonstruktion und Verkettung solltest du den auf alle Fälle auch besser mit einer 3ten Bridge_Priority versehen die höher ist als der Default 32768. Nur um ganz sicher zu gehen das der STP Baum hier sauber kalkuliert wird !!

Die Konfig sähe dann so aus (Instances Aufteilung berücksichtigt aber ohne Load Sharing, da du keinerlei redundante Links hast mit Ausnahme der sehr problematischen Ringe) inkl. LAG/Ethernchannel Konfig.
Willst du wirklich nur mit der Instance 0 arbeiten lässt du die anderen weg !

Core_1#
!
spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
name kevische_netz
revision 1
instance 1 vlan x
instance 2 vlan y
!
spanning-tree mst 0-1 priority 4096
spanning-tree mst 2 priority 4096
!
interface GigabitEthernet0/1
description LAG auf Core_2
switchport mode trunk
channel-group 1 mode active
!
interface GigabitEthernet0/2
description LAG auf Core_2
switchport mode trunk
channel-group 1 mode active
!
interface Port-channel1
switchport nonegotiate
switchport mode trunk

Core_2#
!
spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
name kevische_netz
revision 1
instance 1 vlan x
instance 2 vlan y
!
spanning-tree mst 0-1 priority 8192
spanning-tree mst 2 priority 8192
!
interface GigabitEthernet0/1
description LAG auf Core_1
switchport mode trunk
channel-group 1 mode active
!
interface GigabitEthernet0/2
description LAG auf Core_1
switchport mode trunk
channel-group 1 mode active
!
interface Port-channel1
switchport nonegotiate
switchport mode trunk
!
Core_3#
!
spanning-tree mode mst
spanning-tree extend system-id
!
spanning-tree mst configuration
name kevische_netz
revision 1
instance 1 vlan x
instance 2 vlan y
!
spanning-tree mst 0-1 priority 12288
spanning-tree mst 2 priority 12288
!
interface GigabitEthernet0/1
description LAG auf Core_2
switchport mode trunk
channel-group 1 mode active
!
interface GigabitEthernet0/2
description LAG auf Core_2
switchport mode trunk
channel-group 1 mode active
!
interface Port-channel1
switchport nonegotiate
switchport mode trunk
!

Entspricht ja mehr oder minder genau deinem Konfig Design außer der Prio bei Core 3.
Jetzt die Frage, ob ich auch auf allen Uplinks der Switche, alle VLANs erlauben muss?
Nein !
Dort erlaubst du natürlich nur die VLANs die du auch wirklich brauchst an den Enden.
Es wäre sinnfrei alle VLANs dort zu erlauben auch die die da gar nicht gefordert sind, denn es wird dann sämtlicher Broad- und Multicast Traffic aller dieser VLANs dort gesendet die deine Uplinks belasten und die Performance verschlechtern.
Fazit:
Nur die VLANs forwarden die dort aktiv genutzt sind ! (switchport trunk allow vlan xyz)
Ich kann nicht auf allen Lancoms MSTP einstellen, da die älteren 1224er das nicht unterstützen.
Das ist schlecht aber nicht ganz schlecht !
Gibt es ggf. die Möglichkeit mit einem Firmware Update MSTP dort nachzurüsten ?? Aus Design und Konfig Sicht wäre es besser wenn das gesamte Netz homogen MSTP supporten würde !
Protokollbrüche sind immer eine Quelle möglicher Fehler und Instablitäten. Aber letztlich ist es nicht schlimm, denn MSTP ist zu RSTP kompatibel.

Warum man hier gerade in einem Cisco Umfeld zu allerbilligsten Lancoms gegangen ist ist so oder so vollkommen unverständlich. Da wäre man mit HP oder TP-Link noch 10mal besser gefahren, denn die supporten wenigstens durchgängig MSTP. Hier hat der Entscheider eurer IT Abteilung gründlich auf ganzer Linie versagt. Aber egal...andere Baustelle !

Meine Trunkports sind alle so konfiguriert
Richtig aber das "switchport nonegotiate" kannst (und solltest du) auf reinen Cisco zu Cisco Links weglassen ! Also wo auf beiden Enden Cisco ist.
Dieses Kommando ist nur wichtig auf den Ports die von Cisco zu NICHT Cisco Geräten gehen. Dort solltest du es immer auf der Cisco Seite dann konfigurieren !!

Dann habe ich den Core1 auf MST mit ...umgestellt.
Taktisch war das nicht ganz so klug ! face-sad
Du hättest zuerst die Lancom Ringe von der reinen Cisco Welt isolieren sollen um erstmal ganz stabil die Cisco MST Konfig zum Fliegen zu bringen OHNE das es Seiteneffekte von dazu inkompatiblen Lancom und insbesondere den alten Lancoms gibt.
DAS wäre wichtig gewesen ! Du musst die Lancom Welt erst isolieren (Kabel zum Cisco ziehen) und dann schrittweise zuschalten (Kabel wieder stecken)

Dann fängt man immer mit dem Switch der höchsten Priority, also dem Root Switch (hier Core 1) an.
Lässt den hochlaufen, prüft mit show mst das alle Uplinks im Forwarding sind.
Dann kommt Core 2 ran. Wieder mit show mst checken das die Topologie stimmt.
Dann Core 3 ran. Und wieder mit show mst checken das die Topologie stimmt.
Damit ist dann der gesamte Root Core aktiv und die Topologie sollte gem. Priority stimmen.
Jetzt klemmst du alles restlichen Ciscos dran. Gibst den 3 Minuten das die den Topologie Baum komplett berechnen, löschst mit clear logg die Logs auf allen Switches damit die sauber sind und du ggf. noch irgendwelche flappenden Links oder Topo Changes sauber sehen kannst.
Von den 3 Cores checkst du dann die Topologie, die sauber und stabils sein sollte.
Das Konstrukt lässt du 5-10 Minuten rennen und wenn es keine wilden Topo Changes gibt, dann weisst du das dein Cisco MST Core stabil und "rock solid" auf MSTP Basis arbeitet !!
Checke auch mit show port-channel und mit show lacp das deine Etherchannel /LAGs sauber arbeiten im MSTP.
Erst DANN und wirklich erst dann, kommen die vorher isolierten Lancom Gurken dran !!
So kannst du doch viel besser auf Konfig- oder Topologiefehler reagieren wenn du strategisch und schrittweise vorgehst ! face-wink

Tödlich ist dieser Ring. Den solltest du erstmal offen lassen und die Lancoms nur als Kette anbinden an Core 3 oder Core 1. Und nur einen zuerst, den anderen abgetrennt lassen !
Ideal trennst du den unglücklichen Lancom Ring zw. Switch 3 und 4 auf, so das die Anbindung an Switch 1 annähernd gleich lange Schenkel hat. Wichtig um keine Seiteneffekte durch Ring Loops oder STP Loops zu provozieren !!

Hier im Lancom Umfeld kommt es jetzt darauf an ob dort homogen RSTP rennt oder MSTP.
Was du in jedem Falle vermeiden solltest ist das das auch innerhalb der Lancoms gemischt ist zw. RSTP und MSTP das wäre NICHT gut und gilt es zu vermeiden.
Wenn, dann sollte ein Lancom Ring rein MSTP und einer rein RSTP sein oder besser beide rein RSTP wenn von den uralten Teilen überall welche drin sind.
Erst wenn ein so ein Konstrukt sauber rennt nimmst du den 2ten geöffneten Ring und klemmst den an.
Ganz zum Schluss erst wenn das alles stabil rennt, dann erst schliesst du die Ringe.
Wenn das Konstrukt dann stabil bleibt ist alles gut.
Raten kann man dir nur dringend die unglückliche Ringstruktur wegzulassen und den Ring offen zu betreiben.
Durch die lange kettenartige Struktur läufst du aber auch Gefahr mehr als 7 Layer 2 Hops zu haben im Netz.
Tödlich, denn auch das verstößt gegen grundsätzliche Ethernet Designrichtlinien und wird auf kurz oder lang auch wieder problematisch.
Das ganze Konstrukt ist sehr unglücklich. Speziell diese üblen Ringstrukturen. Das noch mit einem Billighersteller der nur ein Bruchteil der Standards erfüllt ist wagemutig.
Weisst du aber vermutlich selber ?!

Dann war meine Idee, zunächst auf Rapid-PVST umzustellen, um von dort dann auf MST zu gehen
Das ist völliger Unsinn. Solltest du niemals machen, weil das sofort Probleme mit den Lancoms nach sich zieht die NICHT PVSTP kompatibel sind.
Wenn du sowas machst IMMER vorher die NICHT Cisco Geräte abhängen und vom Cisco Netz isolieren !
Grundsätzlich solltest du es immer so machen wie oben beschrieben:
  • Cisco isolieren
  • Nur die Ciscos komplett und umfassend auf MST umstellen. ACHTUNG: Hier braucht der Switch ohne Portfast aktiv zu haben immer ca. 45 Sekunden nach einem Topo Change um in den Forwarding Status zu gehen !!! Ein show mst zeigt dir die Topologie !
  • Erst wenn die Ciscos ALLE sauber und stabil auf MST arbeiten den Rest Schritt für Schritt anhängen !
Cisco PVSTP+ und RSTP sind NICHT kompatibel ! Das wirst du nicht hinbekommen.
Du musst den Cisco Core auf MSTP bringen anders geht es nicht.
Mit dem o.a. schrittweisen Vorgehen, insbesondere dem Isolieren der Lancom Ringe was essentiell ist, gelingt das aber sofort und ohne Probleme !
Mitglied: malawi
malawi 05.12.2017 um 13:36:21 Uhr
Goto Top
Danke aqui, dass du mir so ausführlich beschreibst wie man richtig vorgeht. Ich werde einen neuen Termin planen, an dem ich die Infrastruktur auf MSTP umstelle. Danach schreibe ich hier wieder meine Erfahrungen!

Danke!
Mitglied: aqui
aqui 05.12.2017 aktualisiert um 16:58:20 Uhr
Goto Top
Wie gesagt, optimal ist dein Design nicht und wird immer Risiken bergen solange man nicht irgendwie diese beiden sehr unglücklichen Ringstrukturen auflösen kann und wenigstens halbwegs in einen Stern oder Teilstern migrieren kann.
Vermutlich ist das mal durch jemanden gemacht worden mit wenig Ethernet KnowHow oder erzwungen durch fehlende bzw. nicht vorhandene Uplink Leitungen und so Altlast Historie. Langfristig solltest du da ein Redesign planen sofern die Entscheider da nicht völlig auf der Lancom Billig Rille sind. Das sind keine potenten Backbone Switches sondern billigster Access. Weisst du aber auch sicher alles selbst.

Mit dem 2ten Anlauf wirds auch ganz sicher klappen ! face-wink
Wir sind gespannt...
Mitglied: malawi
malawi 18.02.2019 um 12:22:53 Uhr
Goto Top
So, nach über einem Jahr nun eine Rückmeldung bezüglich des Themas:

Ich hatte damals auf den Core-Switches RSTP konfiguriert und es lief bis heute stabil.

Wir haben aber inzwischen komplett neue Core-Switches angeschafft. Bestehend aus folgenden Komponenten:

9500-40X (Core)
9300-48T (Core-Access)
SG500-XF (Distribution)

Es gibt drei Räume, die im Dreieck zueinander stehen. Hier mal eine Skizze, darin enthalten auch die Spanning-Tree Prioritäten:

stp

Der untere Bereich ist der aktuelle Core. Root-Bridge ist im Raum 3 deshalb, weil dort die meisten Access-Switche angebunden sind.

Das obere Dreieck soll der neue Core werden. Eigentlich ist der Corebereich so ausgelegt, dass Redundanz ohne Spanning-Tree funktioniert. Allerdings haben wir die Möglichkeit das Dreieck zu schließen und somit kommt dann doch wieder Spanning-Tree zum Einsatz. Die Switche sind untereinander gestackt und über PortChannels verbunden.

Nun zu meiner eigentlichen Frage:

Die blaue Verbindung möchte ich am Wochenende stecken. Das ist ein PortChannel zwischen den beiden Core-Switches in Raum 2. Sobald diese Verbindung steht, kann ich die Komponenten Stück für Stück auf den neuen Core-Bereich umziehen.

Die Prioritäten stehen im Bild dabei. Auf den alten Core-Switches (unten) ist durchgehend RSTP konfiguriert. Auf den neuen Core-Switches (oben) ist durchgehend MST konfiguriert. Dort ist aktuell eine Instanz 1 (Revision 1) mit allen VLANs angelegt.

An sich sollte das zusammenstecken der beiden Cores also funktionieren. Der Baum wird einmal neu berechnet und gut. Jetzt habe ich gelesen, dass RSTP mit MST nur in Instanz 0 (CIST) kompatibel ist. Natürlich verunsichert mich das nun etwas. Der Hauptstandort den es hier betrifft, ist die Zentrale für einige weitere Standorte, die bei einem Ausfall auch betroffen sind. Deshalb möchte ich hier noch einmal nachfragen, ob jemand aus Erfahrung mehr dazu sagen kann.

Danke für eure Hilfe!
Mitglied: brammer
brammer 18.02.2019 um 14:07:10 Uhr
Goto Top
Hallo,

mich wundern deine Priorities.....

Laut Cisco sind diese Werte komplett ungültig....
Priority values are 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, and 61440. These are the only acceptable values.


RSPT Priority

brammer
Mitglied: aqui
Lösung aqui 18.02.2019, aktualisiert am 05.04.2022 um 19:33:39 Uhr
Goto Top
In der Tat ! Die Priorities sind vollkommen falsch, denn die dürfen nur Modulo 4096 sein. Oberen 4 Bit der Bridge ID !
Steht im oberen Thread Verlauf ja auch mehrfach. (Siehe auch Threadbeitrag oben).
stp-root
0 ist Hersteller übergreifend nicht eindeutig definiert und sollte man in einem STP Setup niemals verwenden !

Zudem ist es vollkommen sinnfrei allen Switches eine STP Priority zu geben, das sollten nur der Root und der Backup Root Switch sein.
Dadurch ist dann so oder so der Spanning Tree vollkommen eindeutig. Dafür reichen 2 Switches eben Root und Backup Root. Die anderen kann man komplett im Default lassen !
habe ich gelesen, dass RSTP mit MST nur in Instanz 0 (CIST) kompatibel ist.
Das ist Blödsinn !
MSTP basiert ja in sich auf RSTP. Im Grunde ist es RSTP was in mehrfachen Instanzen rennt wenn man es mal ganz einfach betrachtet. Also auch in den anderen Instanzen rennt RSTP.
Die Instanz 0 ist nur in so fern besonders, als das sie die Default Instanz ist und alle VLANs die nicht fest irgendwelchen Instanzen zugeordnet sind landen dann in der Default Instanz 0.
Eigentlich ganz einfach....
Mitglied: malawi
malawi 19.02.2019 um 07:13:22 Uhr
Goto Top
Zitat von @brammer:
mich wundern deine Priorities.....

Laut Cisco sind diese Werte komplett ungültig....

Die Switches haben schon die korrekten Prios, da ich die Prioritäten allerdings aus der Console kopiert habe, habe ich fälschlicherweise aus VLAN1 kopiert, dort wird dann eins dazu gezählt. Also Prioritäten sind korrekt, da STP gestern schon bei einem Failovertest einwandfrei gegriffen hat.

Zitat von @aqui:
Zudem ist es vollkommen sinnfrei allen Switches eine STP Priority zu geben, das sollten nur der Root und der Backup Root Switch sein.
Dadurch ist dann so oder so der Spanning Tree vollkommen eindeutig. Dafür reichen 2 Switches eben Root und Backup Root. Die anderen kann man komplett im Default lassen !
So soll das auch werden. Wie man Im Bild sehen kann, sind dort jeweils zwei Switches mit einer niedrigeren Prio als Default konfiguriert.

Da ich beide Core's, für eine einfachere Migration, nebeneinander laufen lassen möchte, habe ich natürlich die neuen Cores auch direkt mit einer Prio versehen. Daher sind im Bild vier Switches mit angepasster Prio zu sehen. Wenn der alte Core (unten) dann mal abgeschaltet wird, bleiben nur noch Root (Prio 24576) und Backup Root (Prio 28672) übrig. Dann haben wir das von dir beschriebene Szenario.

habe ich gelesen, dass RSTP mit MST nur in Instanz 0 (CIST) kompatibel ist.
Das ist Blödsinn !
MSTP basiert ja in sich auf RSTP. Im Grunde ist es RSTP was in mehrfachen Instanzen rennt wenn man es mal ganz einfach betrachtet. Also auch in den anderen Instanzen rennt RSTP.
Die Instanz 0 ist nur in so fern besonders als das sie die Default Instanz ist und alle VLANs die nicht fest irgendwelchen Instanzen zugeordnet sind landen dann in der Default Instanz 0.
Eigentlich ganz einfach....

Gut, die Bestätigung reicht mir auch schon. Ich wurde durch diese Aussage eben verunsichert, was jetzt aber geklärt ist.

Ich habe gestern noch einmal einen Testswitch (ähnlich wie der Core in Raum 2 unten) konfiguriert um das anflanschen des neuen Core's einmal zu testen. Dabei steckte mein Notebook am neuen Core (oben) und ich konnte alle angeschlossenen Switches per PING erreichen.

Nachdem ich den Testswitch also angehängt habe, habe ich auf dem neuen Core Switch (oben) in Raum 2 folgende Spanning-Tree Ausgabe:
2019-02-18 15_16_37-x

Die Root Bridge ist, wie auch erwartet wurde, nun der Testswitch (bzw. in Real der alte Coreswitch in Raum 2 unten). Allerdings wird der Port dahin geblockt, wie auf dem Bild zu sehen.

Wo kann ich ansetzen?
Mitglied: brammer
brammer 19.02.2019 um 07:18:23 Uhr
Goto Top
Hallo,
Das anschliessen des Laptop kannst du dir sparen... einfach mal in der console ping ohne IP Adresse eingeben... und bei extended Option einfach eine Source Adresse aus dem VLAN nehmen...

Brammer
Mitglied: aqui
Lösung aqui 19.02.2019, aktualisiert am 10.09.2019 um 17:56:19 Uhr
Goto Top
habe ich fälschlicherweise aus VLAN1 kopiert, dort wird dann eins dazu gezählt.
Was aber auch komplett falsch ist !!
Priowerte können nur Vielfache von 4096 sein ! Wenn du dir das obere Bild mit den obersten 2 Bit ansiehst in einem Byte sollte dir das auch schnell selber klar werden wenn dir das Binärsytem geläufig ist !
dort jeweils zwei Switches mit einer niedrigeren Prio als Default konfiguriert.
Stimmt ja nicht ! Dort sind 4! Switches mit einer niedrigeren Prio definiert ! (R1, 2mal R2 und R3). 32768 ist der Default.
bleiben nur noch Root (Prio 24576) und Backup Root (Prio 28672) übrig.
OK, etwas verschwurbelt mit der Switch Nummerierung, dann aber OK.
Fragt sich generell warum du die 2 Cores nicht in einen Stack bringst ??
Die neuen Cisco Cat 9000er supporten doch alle Virtual Stacking ?!
Das würde die Sache doch erheblich vereinfachen ? Du hättest dann einen redundanten Stack als Core, könntest alle angeschlossenen Räume per LACP LAG redundnat über die beiden Core Member anbinden und eliminierst das leidige so STP komplett unter Beibehaltung der Redundanz und zudem noch doppelter Bandbreite in die angeschlossenen Räume.
So sähe ja ein etwas moderneres Konzept aus wenn man schon die teuersten latest and greatest Cisco Catalysten benutzt ?!

stackdesign

Allerdings wird der Port dahin geblockt, wie auf dem Bild zu sehen.
Wo kann ich ansetzen?
Mmmhhh... Nach den Meldungen dahinter (PVST) zu urteilen hast du auf diesen neuen Core Switches KEIN MSTP aktiviert sondern weiterhin Ciscos proprietäres PVSTP+ dort am Laufen !
Das wäre in einem Mix mit MSTP des Restnetzes dann natürlich tödlich, denn beide STP Verfahren sind vollkommen inkompatibel ! Kann das sein ?
Das würde erklären warum der Root Port im Blocking State ist, was er niemals sein dürfte ! Du loopst hier vermutlich das weiterhin aktive PVSTP+ durch deine MSTP Welt.
Da hier aber ein Konfig Auszug und/oder Screenshot fehlt der neuen Catalysten kann man nur raten. face-sad
Mitglied: malawi
malawi 19.02.2019 um 11:11:24 Uhr
Goto Top
Zitat von @aqui:

habe ich fälschlicherweise aus VLAN1 kopiert, dort wird dann eins dazu gezählt.
Was aber auch komplett falsch ist !!
Priowerte können nur Vielfache von 4096 sein ! Wenn du dir das obere Bild mit den obersten 2 Bit ansiehst in einem Byte sollte dir das auch schnell selber klar werden wenn dir das Binärsytem geläufig ist !
Das macht der Switch doch automatisch, ich habe lediglich eine Prio (Modulo 4096) festgelegt und wenn ich dann
show spanning-tree
eingebe, erhalte ich im VLAN0001 diesen Wert.

dort jeweils zwei Switches mit einer niedrigeren Prio als Default konfiguriert.
Stimmt ja nicht ! Dort sind 4! Switches mit einer niedrigeren Prio definiert ! (R1, 2mal R2 und R3). 32768 ist der Default.
Jeweils! Jeder Corebereich hat seine Root und seine Backup-Root. Also insgesamt vier, nach Abschaltung des alten Corebereiches nur zwei.

bleiben nur noch Root (Prio 24576) und Backup Root (Prio 28672) übrig.
OK, etwas verschwurbelt mit der Switch Nummerierung, dann aber OK.
Fragt sich generell warum du die 2 Cores nicht in einen Stack bringst ??
Die neuen Cisco Cat 9000er supporten doch alle Virtual Stacking ?!
Die Switches in den einzelnen Räumen sind bereits gestacked. Das habe ich Aufgrund der Übersichtlichkeit nur nicht dargestellt. Also alle Switches bestehen bereits aus zwei Einzelgeräten.

Allerdings wird der Port dahin geblockt, wie auf dem Bild zu sehen.
Wo kann ich ansetzen?
Mmmhhh... Nach den Meldungen dahinter (PVST) zu urteilen hast du auf diesen neuen Core Switches KEIN MSTP aktiviert sondern weiterhin Ciscos proprietäres PVSTP+ dort am Laufen !
Das wäre in einem Mix mit MSTP des Restnetzes dann natürlich tödlich, denn beide STP Verfahren sind vollkommen inkompatibel ! Kann das sein ?
Das würde erklären warum der Root Port im Blocking State ist, was er niemals sein dürfte ! Du loopst hier vermutlich das weiterhin aktive PVSTP+ durch deine MSTP Welt.
Da hier aber ein Konfig Auszug und/oder Screenshot fehlt der neuen Catalysten kann man nur raten. face-sad
Ich weiß nur nicht wirklich wie ich vorgehen soll. Der alte Corebereich läuft auf RPVST, da dort vor über einem Jahr die Umstellung auf MST nicht funktioniert hat.

Es ist wirklich schwierig dieses historisch gewachsene Netzwerk in den Griff zu kriegen, zumindest aus meiner Sicht.
Mitglied: aqui
Lösung aqui 19.02.2019 aktualisiert um 11:34:58 Uhr
Goto Top
Das macht der Switch doch automatisch
Nein, davon kann man nie ausgehen. Premiumswitches oft ja. Die Masse der Billig- und Websmart Switches (sofern sie denn überhaupt irgendeine Art von STP unterstützen) meist nicht oder nicht richtig. Ganz gefährlich ist hier oft der Wert 0 der nicht definiert ist und viele fälschlich nutzen.
erhalte ich im VLAN0001 diesen Wert.
Unter welchem STP Protokoll ??
STP, RSTP, MSTP, PVSTP, PVRSTP, PVSTP+, PVRSTP+ ??
Cisco fährt im Default VLAN 1 auch parallel zu PVSTP+ ein STP im Single Span Verfahren um kompatibel zu anderen (Billigswitches) zu sein. Das klappt aber nur in EINEM VLAN nicht mit VLAN Switches die STP generell nur im Single Span können !
Also alle Switches bestehen bereits aus zwei Einzelgeräten.
Auch der Core ??
Wenn ja ist das ein Full Stack ?
Wenn ja solltest du dich fragen ob du dir das Thema STP egal mit welchem protokoll dann noch überhaupt antust.
Besser mit LACP LAGs im Backbone arbeiten und dann STP frei.
Ich weiß nur nicht wirklich wie ich vorgehen soll.
Da gibts nur 2 Optionen !
Entweder du hast die alte Struktur nebenbei und isoliert, dann kannst du es parallel aufbauen und verbindest beide Welten über einen gerouteten L3 Link.
Wenn das nicht geht und du nur Teile der alten Welt neu gemacht hast kommst du nicht umhin das Netz mal am Wochenende oder zu betriebsarmen Zeiten mal kurzzeitig totzulegen oder zumindest in Teilen abzutrennen. 1 Std. sollte da reichen bei deiner sehr überschaubaren Anzahl von Core und Access Switches.

Normal geht man dann so vor das man den Core komplett sauber auf MSTP migriert, die Konfig und das MSTP Verhalten checkt.
Dann flanscht man sukkzessive die Acces Stacks ebenfalls unter MST an und checkt ob sich der STP Prozess wie erwartet verhält. Idealerweise fängt man mit dem RZ an wo die wichtigsten zentralen Komponenten stehen. So bekommst du Backbone und RZ dann erstmal in einem stbilen MSTP Umfeld zum laufen.
Dann gehst du sukzessive mit den weiteren Access Stacks ebenso vor.
Du musst dich aber von Anfang an für EIN STP Protokoll auf ALLEN Komponenten entscheiden und diese entsprechend vorkonfigurieren.
Ciscos PVSTP+ ist mit ALLEN anderen STP Protokollen vollkommen inkompatibel, was einen parallelen Betrieb dann vollkommen ausschliesst und auch kontraproduktiv wäre wegen der dann sichewr auftretenden Fehler.
Beide STP Protokolle "sehen" sich nicht und agieren unabhängig was dann in einem Chaos endet.
Also es geht nur entweder oder. Beides, auch nur in Teilen, geht definitiv nicht !
Es ist wirklich schwierig dieses historisch gewachsene Netzwerk in den Griff zu kriegen
Das ist häufig so.
Aber mit max. einer Stunde partieller Downtime bekommst du das dann auch ein für alle Mal in den Griff !
Das ist das Positive !
Mitglied: malawi
malawi 20.02.2019 um 12:36:57 Uhr
Goto Top
Für alle Leser die ein ähnliches Problem haben:

Ich aktiviere den BPDU-Filter auf dem neuen Coreswitch bzw. dessen Uplinkports zum alten Coreswitch.

Theoretisch dürften die beiden Corebereiche dann unabhängig von einander Spanning-Tree fahren.


Mir wurde empfohlen statt auf den BPDU-Filter zu setzen, das Spanning-Tree auf den Uplinkports komplett zu deaktivieren. Allerdings ist das nicht möglich. Ich kann nur das globale Spanning-Tree deaktivieren.

Ich hoffe also, dass der BPDU-Filter ausreicht. Mit meinem Testswitch hat es zumindest funktioniert (ist aber auch nur einer)

Morgen früh habe ich die Downtime geplant...
Mitglied: malawi
malawi 21.02.2019 um 08:56:59 Uhr
Goto Top
Die Verschmelzung der beiden Core-Switches habe ich heute früh durchgeführt.

Funktioniert bisher auch mit dem BPDU-Filter. Einzig ein zweiter Link im Port-Channel verursacht Flapping zwischen Port-Channel und Mitgliedsport.

Ich muss also mit einem GBit-Uplink auskommen.

Jetzt kann ich alles Stück für Stück auf den neuen Core umziehen und habe danach eine saubere MST-Landschaft.

Danke für eure Hilfe!