Network Topology 5.4.0 — jedes Kabel eine eigene Linie

Dieses Release kam aus einem Issue, und der Melder hat es gleich selbst gebaut. Christos Diamantis hat beschrieben, was fehlt, zwei Tage später lag der Pull Request da — mit Tests, die härter sind als meine. Das ist der erste größere Umbau am Modul, der nicht von mir kommt.

Zwei Switches, vier Kabel, eine Linie

Bis 5.3 galt: ein Gerätepaar, eine Kante. Meldete ein Switch seinen Nachbarn ein zweites Mal über einen anderen Port, wurde diese Meldung in die vorhandene Kante hineingefaltet. Der erste Wert gewann.

Für ein LACP-Bündel hieß das drei Dinge, und das dritte ist das eigentliche Problem:

Man sah einen Portnamen, bei 4×10G also einen von vier. Man sah den Verkehr eines Mitglieds — gemessen gegen dessen Kapazität, also 10G statt 40G, und damit eine Auslastung, die viel zu hoch aussah. Und wenn ein Kabel ausfiel, änderte sich auf der Karte nichts. Die Linie stand weiter, weil die übrigen drei sie hielten. Genau der Moment, für den man eine Topologie-Karte aufhängt, war der Moment, in dem sie schwieg.

Jetzt ist jedes Kabel eine Kante

Hineingezoomt fächert das Bündel auf: eine Kurve je Kabel, nebeneinander, jede mit eigenen Ports an beiden Enden, eigenem Verkehr, eigener Auslastung. Ein Mitglied, das nicht mehr gemeldet wird, während seine Geschwister weiterlaufen, ist eine rote gestrichelte Linie mitten zwischen den lebenden.

Herausgezoomt klappt das Bündel zu einer Linie mit ×4 zusammen, mit den Summen beider Enden und bernsteinfarbener Glut, solange ein Kabel tot ist. Wer in einem vermaschten Kern sechs Kabel zwischen jedem Paar hat, schaltet das Auffächern ganz ab — dann bleibt es immer bei einer Linie mit der Zahl daran.

Die Voreinstellung stammt von Christos, und sie ist besser als die, die ich in die Roadmap geschrieben hatte. Auf einer herausgezoomten Karte will niemand mehr Linien; beim Hineinzoomen will man jedes Kabel einzeln. Das bedient beides, ohne dass man etwas umschalten muss.

Die teure Fehlerart ist nicht das übersehene Kabel

Dieselbe Leitung wird von beiden Enden gemeldet, und die Enden sind sich selten einig, wie der Port heißt. Ein Switch sagt 10101, der andere GigabitEthernet1/0/1, und LLDP und CDP nummerieren denselben lokalen Port gern unterschiedlich. Wer daraus naiv „anderer Port, also anderes Kabel" macht, zeichnet jede solche Leitung doppelt.

Deshalb ist die Regel bewusst vorsichtig: Ein Bericht öffnet erst dann ein neues Mitglied, wenn dasselbe Gerät über dasselbe Protokoll bereits jedes bekannte Mitglied auf anderen Ports gemeldet hat. Die Anzahl der Linien stimmt damit auch bei unvergleichbaren Bezeichnungen. Danebenliegen kann die Paarung — welcher Gegenport zu welchem eigenen Port gehört —, nie die Zahl.

Und die Meldung sagt endlich, welches Kabel

Ein ausgefallenes Bündelmitglied ist jetzt eine eigene Änderungsmeldung. Vorher hätte dort gestanden „link core ↔ acc disappeared", und das wäre schlicht falsch gewesen, solange drei von vier Kabeln tragen. So ein Satz schickt jemanden umsonst in den Serverraum, und beim nächsten Mal glaubt er der Meldung nicht mehr.

Jetzt steht da:

cable core Gi1/0/1 ↔ acc Te1/1/1 gone — 3 of 4 still up

Und wenn das letzte Kabel fällt, steht da „the link is down". Eine einzelne Leitung behält die kurze, alte Formulierung — „Kabel 1 von 1 weg" wäre keine Verbesserung.

An welchem Port hängt das Ding?

Das ist die Frage, mit der die meisten überhaupt auf dieses Modul stoßen. Der Access Point ist tot und soll per PoE neu gestartet werden: auf den Switch, show lldp neighbors, gegen die Portbeschreibungen halten, den fehlenden suchen.

Seit 5.3.2 beantwortet ein Klick auf das Gerät das im Panel. Jetzt gibt es die Antwort auch als Spalte in der Tabelle: Gerät und Port der Gegenseite, sortierbar, filterbar (port:Gi1/0/8 im Suchfeld), und über den neuen CSV-Knopf exportierbar. Damit ist die Tabelle eine Patchliste, die man ausdrucken und gegen die Dokumentation halten kann — Gerät und Port stehen in der Datei in zwei getrennten Spalten, weil man in der Tabellenkalkulation nach Switch gruppieren und nach Port sortieren will.

Der schönste Teil daran ist ein Nebeneffekt: Kanten verschwinden nicht, sie altern. Bei einem Gerät, das schon weg ist, steht deshalb noch der Port da, an dem es zuletzt hing — mit einem kleinen Uhrensymbol daneben. Genau der Port, der gesucht wird.

Was noch dazukam

Eine ifSpeed von 4294967295 ist keine Geschwindigkeit, sondern die Decke eines 32-Bit-Zählers: Ein 10G-Port meldet genau diese Zahl und die Wahrheit in ifHighSpeed. Im Panel stand „0.0 % von 4.3 Gb/s", und jede Auslastungsangabe auf so einem Link war mit derselben Zahl falsch gerechnet. Der Wert wird jetzt verworfen; ohne ifHighSpeed bleibt die Geschwindigkeit unbekannt statt erfunden.

Rote Kanten meinten den Host, nicht den Link. Die Farbe kam aus einer Quote über alle Interfaces beider Endpunkte — bei einem Switch mit 17 von 31 ungenutzten, aber administrativ aktiven Ports also über der Hälfte, und damit leuchtete jede seiner Verbindungen rot, während das Panel daneben null Fehler für den betroffenen Port zeigte. Jetzt entscheidet der Zustand des Ports, an dem die Kante hängt.

Dazu: Portnamen, die nur auf einer Seite standen. Ein „Auto"-Layout, das eine gespeicherte Anordnung wiederverwendete, die 30 von 157 gezeichneten Knoten abdeckte. Und der Geisterfilter heißt jetzt „without endpoints" statt „network gear only" — und sagt, wenn er nichts filtern kann, weil kein Nachbar seine Fähigkeiten meldet.

Die Dashboard-Kacheln

Das Topologie-Widget zeichnet weiter eine Linie je Gerätepaar — eine Kachel ist zu klein für einen Fächer. Es zählt die Kabel aber jetzt, statt sie stillschweigend wegzuwerfen: ×4, und ×4 (1 down), wenn eins tot ist.

Und eine Korrektur in eigener Sache: Hier stand seit Juli, die Widgets bräuchten Zabbix 7.4 und blieben auf 7.0 auf „Loading…" hängen. Das stimmt nicht mehr. Auf einer 7.0.30 liegen jetzt alle fünf auf einem Dashboard und rendern, Karte samt ×2, KPI, Health-Score, Tabelle, Items. Woran es im Juli auf 7.0.28 lag, habe ich nicht geklärt — die Begründung, die ich damals danebengeschrieben hatte („die Widget-JS-Basisklasse unterscheidet sich"), war jedenfalls falsch: die Klasse ist auf beiden Versionen Methode für Methode dieselbe.

Läuft wo?

Zabbix 7.0 LTS und 7.4, AGPL-3.0, keine Build-Tools nötig. Getestet auf 7.0.30, 7.4.12, 7.4.14 und 7.4.15. Update von 5.3.x: Dateien ersetzen, php-fpm neu laden, einmal hart neu laden. Kein Scan directory, kein Template-Wechsel.

Zwei Dinge, die direkt auffallen werden. Ein Gerätepaar mit mehreren Kabeln ist ab sofort mehrere Linien — wem das in einem vermaschten Kern zu viel wird, schaltet View → All parallel links aus. Und die erste Aktualisierung nach dem Update ist laut: Die Vergleichsbasis kannte einen Schlüssel je Paar und kennt jetzt einen je Kabel, deshalb meldet ein 4er-Bündel einmalig drei „weitere Kabel". Einmal, pro Benutzer, dann ist Ruhe.

Danke

An Christos Diamantis für Issue und Pull Request — für den Umbau selbst, für die Tests, und dafür, dass seine Voreinstellung meine ersetzt hat. An den Melder, der mir per Mail Screenshots und die Latest-Data-Liste geschickt hat: vier der Korrekturen oben stammen aus diesem einen Thread.