MSTP mit HP ProCurve

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