Skip to content

MSTP mit HP ProCurve

Das Spanning Tree Protocol (STP) ist ein Protokoll, das den Betrieb von lokalen Netzen (z.B. auf Ethernet-Basis) mit Redundanzen erleichtern soll. Diesen Job macht es "reasonably well", ich möchte an dieser Stelle aber nicht unerwähnt lassen, dass es auch schon zu grauen Haaren beim einen oder anderen Netzwerker geführt hat. Es gibt es in vielen verschiedenen Darreichungsformen, und in diesem Artikel möchte ich versuchen, die Grundlagen so weit aufzuarbeiten dass ich dann zu meinem aktuellen Projekt, MSTP, auch noch etwas schreiben kann.

Ein gewaltiger Fallstrick beim Betrieb von Ethernet ist, dass das Protokoll keinen Time-To-Live-Mechanisus hat, und ein Frame, das sich aus irgendwelchen Gründen zwischen zwei oder mehr Geräten im Kreis dreht, dies somit bis zum Ausfall des Netzes oder manuellem Eingriff weiter tut, bis in alle Ewigkeit.

Dieses Verhalten gepaart mit dem Wunsch vieler Netzwerkbetreiber nach üblicherweise durch den Bau von Ringen ausgedrückter Redundanz im Netz, der Eigenschaft von IP over Ethernet, dass Switches Broadcastpakete auf allen Ports rausflooden müssen _und_ der Tatsache, dass das für IP essentiell notwendige Address Resolution Protocol (ARP) zwingend mit Broadcasts arbeitet, führt in der Abwesenheit von Sicherungsmechanismen wie STP zu Broadcaststürmen, deren Auftreten sich in aller Regel massiv negativ auf den Netzwerkbetrieb auswirkt.

Das Heilmittel gegen solche Katastrophen heißt wie schon in diesem Artikel erwähnt Spanning Tree. STP erkennt in einer Netzwerkstruktur Zyklen und trennt diese Zyklen durch Abschalten einzelner Ports auf, so dass ein zyklenfreier Graph aus Netzwerklinks entsteht. Wenn nun dieser zyklenfreie Graph durch Störungen in zwei Teile zerfällt, wird das von STP erkannt und die abgeschalteten Ports wieder so eingeschaltet, dass der Graph wieder zusammenhängend ist. Er sieht dann zwar anders aus als zuvor, aber er ist wieder zusammenhängend und die Kommunikation kann wieder funktionieren.

Das heute in einfachen Netzen eingesetzte Spanning Tree Protokoll ist üblicherweise Rapid Spanning Tree, das sich vom klassischen STP - der Name lässt dies schon vermuten - dadurch unterscheidet, dass es nach Topologieänderungen schneller wieder einen stabilen Zustand erreicht.

STP und RSTP arbeiten allerdings auf Portbasis. Das wird dann interessant, wenn VLANs im Einsatz sind, denn diese beiden einfachen Protokolle schalten Ports ab, ohne sich für die auf den Ports konfigurierten VLANs zu interessieren. Hier ein Beispiel:

 ---------
 | sw11  |---------------------|
 ---------  1                  |
     |  2          Data        |
     |             Center      |
     | 401,403                 | 401,402,403
     |                         |
     |                         |
     |  2                      | 1
 ---------   401,402,403   ---------
 | sw12  |-----------------| sw 13 |
 --------- 13           13 ---------
Wir haben hier drei Switche, in einem Ring aufgebaut, mit drei VLANs: 401, 402 und 403. Nun ist VLAN 402 auf dem Link zwischen Switch 11 und Switch 12 nicht konfiguriert. Entscheidet sich RSTP nun dazu, zur Auflösung des Rings den Link zwischen Switch 12 und Switch 13 abzuschalten, ist Switch12 in VLAN 402 nicht mehr erreichbar - ein Zustand, den wir üblicherweise nicht haben wollen.

Das hat mich seinerzeit bei meinem ersten komplexeren Netzprojekt mit HP ProCurve-Switchen überrascht, weil sich die Cisco-Switche, mit denen ich davon gearbeitet habe, anders verhalten: Cisco benutzt sein proprietäres Protokoll PVST (Per-VLAN Spanning Tree), was für jedes VLAN einen eigenen Spanning Tree verwendet. Im oben gezeichneten Beispiel würde PVST also für die VLANS 401 und 403 je einen Ring sehen und diesen Ring auftrennen. VLAN 402 würde PVST jedoch in Ruhe lassen, denn VLAN 402 hat keine Zyklen. Erster Lerninhalt: Das was Cisco macht, ist proprietär und funktioniert nur mit Cisco. Zweiter Lerninhalt: Wenn man RSTP mit HP-Gear macht, muss man auf allen Interswitchlinks alle VLANs transportieren, sonst passieren grausame Dinge. Auf einem so einfachen Netz mit drei Switches ist das natürlich kein Problem. Wohl aber, wenn man z.B. VLANs benutzt, um nicht alle Daten an allen Stellen im Netz zugänglich zu haben.

Wenn man das Ergebnis von PVST mit HP-Gear nachbauen will, verwendet man MSTP, das Multiple Spanning Tree Protocol. Beim MSTP definiert man unterschiedliche Spanning-Tree-Instanzen und ordnet ein oder mehrere VLANs den Instanzen zu. Leider ist das so komplex, dass man in einem so einfachen Setup mit nur drei Switchen wie oben gezeichnet mit MSTP nicht weit kommt; wenn man das wirklich am Fliegen sehen möchte, sollte man mehrere Ringe bauen können. Netterweise hat $KUNDE hierfür sieben Switche bereitgestellt, die mir für einige Wochen zum Testen zur Verfügung standen. Meine Testumgebung würde auch mit zwei Switchen weniger funktionieren, aber das Werfen von mehr Hardware hat noch ein bisschen besseren Einblick gegeben.

Und so sah das ganze Spiel aus:

 Access
      | 9
 ---------
 | sw11  |---------------------|
 ---------  1                  |
     |  2          Data        |
     |             Center      |
     | 401-403t                | 401-403t
     | 1u                      | 1u
     |                         |
     |  2                      | 1
 ---------   401-403t      ---------
 | sw12  |-----------------| sw 13 |
 --------- 13  1u       13 ---------
     | 24                   25 |
     |                         |
     | 401t, 403t              | 401t, 403t
     | 1u                      | 1u
     |                         |
     | 24                   25 |
 ---------                 ---------
 | sw24  |                 | sw 25 |
 ---------                 ---------
     | 26                   27 |
     |                         |
     | 401t, 403t              | 401t, 403t
     | 1u           offices    | 1u
     |                         |
     | 26                   27 |
 ---------    401t,403t    ---------
 | sw26  |-----------------| sw 27 |
 --------- 28    1u     28 ---------
Die Switches 11, 12 und 13 stehen in einem simulierten Rechenzentrum und bilden für sich einen Ring. Die Switches mit den Zwanziger-Nummern sind über ein gedachtes Gebäude verteilt und binden die Arbeitsplatzrechner an. Das VLAN 402 transportiert rechenzentrums-interne Daten; seine Inhalte sollten in den Büroräumen nicht abgreifbar sein. Das VLAN 1 dient dem Switchmanagement und wird auf allen Links "untagged" transportiert.

Daraus entstand dann die folgende Switch-Konfiguration (in der für ProCurve 2848 relevanten Notation; die neueren 2810-48G weichen hier in Details ab) für alle Switche:

vlan 1
   name "DEFAULT_VLAN"
   untagged 1,2,9,13,24,25,26,27,28
   ip address 10.3.1.<switch> 255.255.255.0
   exit
vlan 401
   name "VLAN401"
   ip address 10.3.11.<switch> 255.255.255.0
   tagged 1,2,9,13,24,25,26,27,28
   exit
vlan 403
   name "VLAN403"
   ip address 10.3.13.<switch> 255.255.255.0
   tagged 1,2,9,13,24,25,26,27,28
   exit
spanning-tree
spanning-tree protocol-version MSTP
spanning-tree config-revision 2
spanning-tree instance 1 vlan 401 403
Die 10er-Switche haben noch zusätzlich:
vlan 402
   name "VLAN402"
   ip address 10.3.12.<switch> 255.255.255.0
   tagged 1,2,9,13
   exit
spanning-tree instance 2 vlan 402

Diese Materialschlacht funktioniert so wie beabsichtigt: Obwohl das VLAN 402 nicht mehr auf allen Switchen konfiguriert ist, sind alle Switche im Normalbetrieb in allen VLANs erreichbar. Auch das Ziehen einzelner Patchkabel stört den Betrieb nicht; der simulierte Ausfall eines ganzen Switches (Stromstecker raus) macht nur den einzelnen Switch unerreichbar. Die durch die Rekonfiguration des Spanning Tree zweifellos entstehende Unterbrechung ist kurz genug, dass ein im Sekundentakt abgesetztes ping die Störung nicht bemerkt.

Anders ist es allerdings, wenn man die so erzeugte Störung behebt: Dabei verschluckt sich der Spanning Tree für etwa fünfzehn Sekunden, bevor wieder alle Switche erreichbar sind. Während dieses Verschluckens kommt es regelmäßig vor, dass auch Switche in der näheren Umgebung der Störung kurz nicht mehr erreichbar sind. Das ist wenig schön, aber in diesem Zeitrahmen IMO akzeptabel.

So lange mir die Testhardware noch zur Verfügung steht, werde ich eine Prozedur entwickeln, ein Netz im laufenden Betrieb auf MSTP umzustellen.

Sehr hilfreich bei dieser Operation war übrigens mein serieller Konsolen-Server für Arme, denn es debugged sich deutlich leichter, wenn man die Konsolenausgabe aller Switche gleichzeitig im Blickfeld hat. Syslog bringt's hier nicht, denn wenn der Switch grad nicht erreichbar ist, wird er auch keine syslog-Einträge los. Das Gegenstück zu Ciscos "term mon"heißt bei HP übrigens

debug destination session
debug all
no debug lldp

Konfigurationsfehler verhindert man dadurch, dass man die Konfiguration nicht manuell vornimmt, sondern für alle Switche mit einem kleinen Shellscript generiert und per tftp auf die Switche schiebt. Das hat den Vorteil, dass Fehler wenigstens systematisch auf allen Switches gemacht werden (was mich drei Tage für die Fehlersuche gekostet hat, **grml**).

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Patrick on :

Na ja, soooo krasse Raketenforschung ist MSTP auch wieder nicht. ;-) Zudem ist es nicht ganz so propretär wie PVST, immerhin ist es in IEEE 802.1Q definiert.

OhNoo on :

Moin Marc!

Das ist leider nicht sauber konfiguriert. D.h., die 10er-Switches dürften sich, deiner Config nach zu urteilen, nicht in der gleichen Region befinden, wie die restlichen Switches (hier leider nicht zu erkennen, da du keine nachträglichen show-Befehle geposted hast, die für die Verifizierung der MSTP-Config von hoher Wichtigkeit sind). Hättest du das gemacht, wärst du wahrscheinlich auf Inkonsistenzen gestoßen. Es scheint alles gut zu funktionieren, leider jedoch nicht wie ursprünglich von dir gewollt.

Deine 10er Switches würden, so wie hier konfiguriert, im CST (Common Spanning Tree) laufen. Dem CST zugehörig sind alle VLANs, die nicht explizit an eine andere Instanz gebunden sind, bzw. Geräte, die kein MSTP unterstützen (STP/RSTP-Devices). Du hast das VLAN 402 auf den 10er-Switches zwar in die Instance 2 geschoben, da dieser Eintrag jedoch nicht auch auf den restlichen Switches vorhanden ist, sind die 10er-Switches einer anderen Region zugehörig.

Die Switches müssen bzgl. der MSTP-Konfiguration ALLE gleich konfiguriert sein (bis auf die Prio's), da ein sogenannter "MST Configuration Digest-Wert" generiert wird, der letztendlich aussagt, ob alle Switches zur gleichen Region gehören (z.B.: sh spanning-tree mst-config... MST Configuration Digest : 0xCEE35B186F22499C3A91F22820E2293A). Unterscheidet sich dieser Wert auf SwitchA von dem auf SwitchB, sind diese Geräte lediglich im CST und sprechen kein MSTP untereinander. Beim MSTP ist der sogenannte IST (Internal Spanning Tree) das, was im Output schick und richtig aussehen muss (z.B IST Regional Root MAC Address : 001f28-000xyz, etc.). Deine Zeile: "spanning-tree instance 2 vlan 402" muss also auf ALLEN Switches vorhanden sein und nicht nur zusätzlich auf den 10ern. Dabei ist es irrelevant, ob das VLAN Interface auf den restlichen Switches konfiguriert ist oder nicht. Ein Switch kann demnach in der MSTP-Config VLANs enthalten, die nicht als Interface angelegt sind (Was in deinem Fall für das VLAN 402 auf den 20er-Switches zutrifft).

Auszug aus einem HP Manual bzgl. des Digest: [Note: The switch computes the MSTP Configuration Digest from the VID to MSTI configuration mappings on the switch itself. As required by the 802.1s standard, all MSTP switches within the same region must have the same VID to MSTI assignments, and any given VID can be assigned to either the IST or one of the MSTIs within the region. Thus, the MSTP Configuration Digest must be identical for all MSTP switches intended to belong to the same region. When comparing two MSTP switches, if their Digest identifiers do not match, then they cannot be members of the same region.]

Desweiteren ist es unschön, keine Prioritäten festzulegen. Eine Default-Prio von 32768 auf allen Switches zwingt die Geräte dazu, die Root-Bridge selbstständig anhand der MAC-Addresse zu definieren. Du sagst deinem Netz also nicht wer der Chef im Ring ist. Das kann in größeren Netzen fatale Auswirkungen haben. Bei der MSTP-Konfiguration in einem heterogenen Netz, ist es zusätzlich wichtig, die Prio's für "Nicht-MSTP-kompatible"-Devices festzulegen (sowohl für die Root-Bridge, als auch für die alternative 2nd-Root-Bridge). Bei Procurve wäre das z.B. auf Core1: spanning-tree priority 2 (äquivalent zu 8192) und auf Core2: spanning-tree priority 4 (äquivalent zu 16384). Bei MSTP müssen diese Prioritäten zusätzlich in den einzelnen Instanzen verankert sein (Für eine Lastverteilung üblicherweise vertauscht). z.B.: Core1: (ohne die restlichen MSTP-Paramter) spann inst 1 vlan 1,3,5,7 spann inst 1 prio 2 spann inst 2 vlan 2,4,6,8 spann inst 2 prio 4 spann prio 2 z.B.: Core2: (ohne die restlichen MSTP-Paramter) spann spann inst 1 vlan 1,3,5,7 spann inst 1 prio 4 spann inst 2 vlan 2,4,6,8 spann inst 2 prio 2 spann prio 4

Das Thema ist leider nicht ganz so untrivial und bedarf einer sauberen Planung. Auch sollte man sich Gedanken über die (derzeit) nicht verwendeten VLANs machen und diese in unterschiedlichen Instanzen mit einplanen, damit man später nicht alle Switches im Netzwerk hinsichtlich MSTP neu konfigurieren muss, wenn man ein neues VLAN benötigt. Best Practice ist hierbei, sich verschiedene Ranges zu definieren (VLAN 1-100 Inst. 1; VLAN 101-200; Inst. 2; VLAN 201-4096 Inst. 3), so dass man neue VLANs nach Instanz und Prio auswählt.

Hoffe geholfen zu haben :-). Greetz! O.

P.S.: Zu Patrick ist zu sagen, dass es entweder etwas proprietäres gibt oder halt nicht aber nicht "nicht ganz so proprietär. Wobei MSTP zwar mit IEEE 802.1Q zusammenhängt, trotzdem aber als Standard IEEE 802.1s verabschiedet wurde.

Marc 'Zugschlus' Haber on :

Die Prioritäten hatte ich im Artikel im Interesse der Kürze weggelassen; in der Realität ist das natürlich da.

Dass die 10er-Switches im "gedachten" Datacenter in einer eigenen Region liegen, hab ich so beabsichtigt. Genau dafür unterstützt MSTP doch Regionen, oder?

Wenn Du magst, können wir das gerne per Mail oder Jabber direkter auskaspern; Blogkommentare finde ich hiefür denkbar ungeeignet. Meine Mailadresse funktioniert.

Grüße Marc

Kalle on :

Hallo,

vielen Dank für diesen Beitrag. Ich habe paar kleine Fragen, ich hoffe das ist okay.

Ich habe 4 Core Switche ( in einem Ring) und 10 weitere Stockwerksverteiler Switche mit jeweils zwei Uplinks auf zwei Core Switche verteilt. Das Spanning Tree (rstp) funktioniert leider nicht so gut, wir haben sehr viele Topologyveränderungen.

Ich würde das ganze auf MSTP umändern wollen. Auf den Stockwerksverteiler Switchen haben wir nur ca 10 VLANS auf den Cores ca 20 ( Storage Vlans usw ) , wenn ich auf MSTP wechsele müssen dann die Storage VLANS auch auf den Access Switchen ( Stockwerksverteiler Switchen) angelegt sein oder reicht es diese nur in den Instanzen anzugeben.

Ist es Sinnvoll für jedes VLAN was wichtig ist, eine eigene Instance anzulegen ? Wie definiert man die Prioritäten am besten ?

Es sind bei MSTP dann ja alle Uplinks aktiv , was passiert wenn ein Pfad im Ring ausfällt ? sind dann weiterhin alle VLANS verfügbar ?

Wäre diese Konfiguration so in Ordnung ?

Core 1: spanning-tree spanning-tree config-name "MSTP" spanning-tree config-revision 1 spanning-tree instance 1 vlan 1-50 spanning-tree instance 2 vlan 51-131 spanning-tree instance 3 vlan 132-250 spanning-tree instance 4 vlan 251-1199 spanning-tree instance 5 vlan 1200-4094

Core 2: spanning-tree spanning-tree config-name "MSTP" spanning-tree config-revision 1 spanning-tree instance 1 vlan 1-50 spanning-tree instance 2 vlan 51-131 spanning-tree instance 3 vlan 132-250 spanning-tree instance 4 vlan 251-1199 spanning-tree instance 5 vlan 1200-4094 Core 3: spanning-tree spanning-tree config-name "MSTP" spanning-tree config-revision 1 spanning-tree instance 1 vlan 1-50 spanning-tree instance 2 vlan 51-131 spanning-tree instance 3 vlan 132-250 spanning-tree instance 4 vlan 251-1199 spanning-tree instance 5 vlan 1200-4094 Core 4: spanning-tree spanning-tree config-name "MSTP" spanning-tree config-revision 1 spanning-tree instance 1 vlan 1-50 spanning-tree instance 2 vlan 51-131 spanning-tree instance 3 vlan 132-250 spanning-tree instance 4 vlan 251-1199 spanning-tree instance 5 vlan 1200-4094

AccesSwitch1: spanning-tree spanning-tree config-name "MSTP" spanning-tree config-revision 1 spanning-tree instance 1 vlan 1-50 spanning-tree instance 2 vlan 51-131 spanning-tree instance 3 vlan 132-250 spanning-tree instance 4 vlan 251-1199 spanning-tree instance 5 vlan 1200-4094

AccesSwitch 2:

spanning-tree spanning-tree config-name "MSTP" spanning-tree config-revision 1 spanning-tree instance 1 vlan 1-50 spanning-tree instance 2 vlan 51-131 spanning-tree instance 3 vlan 132-250 spanning-tree instance 4 vlan 251-1199 spanning-tree instance 5 vlan 1200-4094

Marc 'Zugschlus' Haber on :

Hallo,

das ist aber lange her ;-)

Nach meinem - durch den Kommentar von OhNoo verunsicherten - Verständnis definierst Du in einer MSTP-Instanz alle VLANs, die Du im Core und auf den Access-Switches haben möchtest, und in einer zweiten alle VLANs, die den Core nicht verlassen sollen.

Auf den Access-Switches definierst Du die VLANs, die den Core nicht verlassen sollen, nicht, und überträgst auch auf den Trunk-Ports zwischen Core und Access diese VLANs nicht.

Was die Prioritäten angeht, würde ich vermutlich zwei der Coreswitches als "primäre" und "sekundäre" Bridge ausgucken und denen die Prioritäten so setzen, dass der "primäre" die Root Bridge wird, und der "sekundäre" diese Rolle übernimmt wenn der "primäre" weg ist. Und sicherheitshalber den Access-Switches eine noch schlechtere als die anderen Coreswitches.

Die Idee von Spanning Tree ist, dass durch Abschalten einzelner Links die vorhendenen Ringe aufgelöst werden. Es wird der Link abgeschaltet, der am weitesten weg von der Root Bridge ist. Fällt ein Link aus, so dass das Netz in zwei Teile zerfallen würde, wird der abgeschaltete Link an dieser Stelle wieder dazugenommen, dass das Netz wieder "eins" ist.

Ich bin übrigens selbständig mit Beratung im Netzwerk- und Securitybereich. Wenn Du professionelle Unterstützung einkaufen möchtest, kannst Du gerne an die Mailadresse schreiben, die sich hinter meinem Namen unter diesem Kommentar verbirgt. Oder Du guckst auf http://uri.zugschlus.de/xingprofil

Add Comment

Markdown format allowed
Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.
E-Mail addresses will not be displayed and will only be used for E-Mail notifications.
Form options