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üssenund 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 ---------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 ---------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:
Die 10er-Switche haben noch zusätzlich: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
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**).