Möhrenfeld

Vorsicht, Netzwerk-Nerd-Artikel voraus! :-) Wer mit Spanning-Tree, BPDU, MSTP und ähnlichen Begriffen nichts anfangen kann wird vermutlich viel unverständliches lesen. Für meine nicht-netzwerkenden Freunde und Bekannten: Ja, das ist es was ich so in meinem Job mache. "Du machst doch was mit Computern" lasse ich aber meistens auch gelten.

1. Das Problem

Wir benutzen in unserem LAN MSTP(Wikipedia, Cisco). Nicht weil wir unbedingt multiple Instanzen bräuchten, sondern weil die Switche von Cisco und HP sich darauf einigen können und (eigentlich) kooperieren. Das klappt auch ganz gut, bis auf einen Procurve 2650 Switch welcher aus unbekanntem Grund immer behauptet hatte er selbst wäre seine eigene MSTP-Region und auch gleich die Root-Bridge in dieser Region. Software-Update, Konfigurationsänderungen, alles hat nichts gebracht.

Auf den Ciscos kam bei show spanning-tree immer nur ein lapidares:

Gi2/12           Desg FWD 20000     128.76   P2p Bound(PVST)

Der Port GigabitEthernet2/12 (Uplink des HP Switches) war also ein PVST Boundary Port, dahinter sollte angeblich eine andere Spanning Tree Version laufen. Das lustige daran, selbst wenn man auf dem Procurve Spanning Tree komplett abschaltete, wurde der Port von der Cisco als Boundary Port markiert. (Hier bin ich zwar zum ersten Mal stutzig geworden, kam aber noch nicht auf die richtige Antwort).

2. Suchen nach dem Licht am Ende des Tunnels

Ein- und Ausschalten von Spanning Tree auf dem Procurve brachte die Erkenntnis, dass das Spanning Tree dort nach dem Einschalten ein paar Sekunden lang korrekt läuft, dann jedoch plötzlich eine eigene MSTP-Region "eröffnet". Schön hier zu sehen:

stp: IST Root changed from 32768:000f20-xxxxxx to 24576:0017e0-xxxxxx
stp: IST Root changed from 24576:0017e0-xxxxxx to 32768:000f20-xxxxxx

Die erste Zeile ist gut (IST Root ist der Cisco), die zweite Zeile hat mir Kopfschmerzen bereitet (IST Root ist der HP selbst). Sogar die Priorität der Cisco ist höher! (24576 vs. 32768, je kleiner die Zahl desto höher die Priorität). Trotzdem keine Chance. Da der Procurve genau keine Möglichkeit hat Spanning Tree zu debuggen blieb nur die Cisco übrig. Ein debug spanning-tree mstp boundary brachte dort folgende Meldungen (Nach einem clear spanning-tree detected-protocols interface Gi2/12):

MST[0]: Gi2/12 mcheck - clearing BOUNDARY flag
MST[0]: Gi2/12 PVST simulation - setting BOUNDARY flag

Wieder: Die erste Zeile ist gut, das Boundary Flag ist weg. Die zweite Zeile hat mich dann so richtig aus dem Konzept gebracht. Wieso zum Henker setzt der Cisco das Boundary Flag? Spanning Tree auf dem HP war zu dieser Zeit ausgeschaltet. Also was veranlasst den Cisco, so zu reagieren? Ohne Grund würde er das ja (hoffentlich) nicht einstellen. Da sonst nichts ausgegeben wurde musste das Debugging etwas erweitert werden, mittels debug spanning-tree bpdu receive. Dort kam nun, nach einem erneuten Löschen des erkannten Spanning Tree Protokolls auf dem Interface, endlich etwas sinnvolles im Log:

STP: MST0 rx BPDU: config protocol = mstp, packet from GigabitEthernet2/12  ,
        linktype SSTP , enctype 3, encsize 2 
STP: enc 01 00 0C CC CC CD 00 03 5A 2B A0 C1 00 0C AA AA 03 00 00 0C 01 0B 
STP: Data     00000080
STP: MST0 Gi2/12:0000 00 80

Auf dem Port kam also ein BPDU vom Typ SSTP an. SSTP ist aber eine Spanning Tree Abart von Cisco selbst. Und mir war bisher nicht bewusst, dass irgendwas in unserem Netz so etwas verschicken würde. Glücklicherweise war noch etwas anderes zu sehen, und zwar die MAC-Adressen. 01 00 0C CC CC CD ist bei SSTP-Paketen immer die Ziel-MAC. Die Bytes danach(00 03 5A 2B A0 C1) sollten also die Source-MAC sein. Eine Suche nach dieser MAC-Adresse in der ARP-Table brachte zwar leider kein Ergebnis, doch nach weglassen der letzten Gruppe (C1) bekam ich eine MAC-Adresse mit C0 am Ende in der ARP-Table angezeigt. Aha! Eventuell ist dass das richtige Gerät. Ein nmap (hoffentlich liest das BKA nicht mit) auf die IP-Adresse offenbarte einen offenen Telnet- und Finger-Port, was doch schon sehr starke Anzeichen für ein Netzwerkgerät waren.

3. Happy End und Ärger mit Procurve

Ein Login auf dem Gerät hat dann bestätigt was ich hier schon vermutete: Es war eine alte Cisco C2900XL, auf welcher Spanning Tree eingeschaltet war. Diese Cisco war irgendwann einmal aufgestellt und dann vergessen worden.

Wieso ist mir das nicht gleich eingefallen? Mir war so ein Gedanke schon gekommen, und zwar als ich festgestellt hatte, dass das Boundary-Problem auch auftrat wenn Spanning Tree auf dem HP gar nicht an war. Aber zu dem Zeitpunkt dachte ich mir: Kann ja gar nicht sein, auf allen Nicht-Uplink Ports auf dem HP ist ja spanning-tree bpdu-filter gesetzt. Dies sorgt dafür, dass auf diesen Ports keine BPDUs gesendet oder angenommen werden (Edge-Port). Und nun der Fehler im Plan: PVST-BPDUs bzw. in diesem Fall SSTP-BPDUs werden von diesem Filter anscheinend nicht erkannt und deshalb auch nicht gefiltert. Der BPDU Filter auf dem Procurve versagt in diesem Fall komplett.

Nachdem diese Erkenntnis da war ging die Lösung ganz schnell: Auf dem Uplink-Port der alten Cisco C2900XL ein spanning-tree bpdufilter enable und der Spuk war zu Ende. Übrig blieb nur die Frage wie weit man dem BPDU Filter auf dem HP Procurve überhaupt trauen kann. Das wird sich erst noch zeigen müssen.