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

Hallo,


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

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.
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.
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.
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

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.
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.
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)
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 !

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 !!

Taktisch war das nicht ganz so klug !
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 !

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 ?!

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 !

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 !
Wir sind gespannt...

Hallo,

mich wundern deine Priorities.....

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


RSPT Priority

brammer

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).
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 !
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....

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

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 !
Stimmt ja nicht ! Dort sind 4! Switches mit einer niedrigeren Prio definiert ! (R1, 2mal R2 und R3). 32768 ist der Default.
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 ?!


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.

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.
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 !
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.
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 !
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 !