Acht Jahre Stille, und endlich eine Juniper-EX-Vorlage, die Virtual Chassis versteht

Acht Jahre Stille—und endlich eine Juniper-EX-Vorlage, die Virtual Chassis versteht

Es gibt etwas einzigartig Frustrierendes daran, die perfekte Open-Source-Vorlage zu finden … und dann zu merken, dass sie seit acht Jahren nicht angefasst wurde. Der Code funktioniert. Größtenteils. Die Struktur ist da. Aber die Zeit ist weitergegangen. Firmware hat sich verändert. Zabbix hat sich weiterentwickelt. Virtual Chassis wurde in echten Deployments zum Standard. Und die Vorlage? Eingefroren im Jahr 2016.

Das ist der Hintergrund dieses neuen Forks der Juniper-EX-Switch-Vorlagen. Ein Pull Request wurde beim ursprünglichen Repository eingereicht, aber angesichts seines langen Winterschlafs spielt sich das eigentliche Geschehen im Fork ab. Und ehrlich gesagt ist es genau so, wie Infrastruktur-Tooling überlebt—jemand steht auf und zieht es in die Gegenwart.

Getestet auf EX2300-, EX3400- und EX3300-Modellen mit Zabbix 7.0.4, ist das keine theoretische Kompatibilität. Es ist im Labor getestet, mit echter Hardware validiert. Dieses Detail zählt. Netzwerk-Vorlagen verzeihen nichts. Ein OID-Mismatch oder eine falsche Index-Annahme, und plötzlich werden die Hälfte Ihrer Items nicht mehr unterstützt.

Aber das eigentliche Highlight-Feature ist nicht die grundlegende Kompatibilität. Es ist die Virtual-Chassis-Discovery.

Wenn Sie schon mal mit Juniper-EX-Stacks gearbeitet haben, wissen Sie, dass Virtual Chassis alles verändert. Was wie ein einzelner Switch aussieht, sind in Wirklichkeit mehrere Mitglieder—jedes mit eigener Rolle, Firmware, MAC-Adresse und Betriebsstatus. Ohne saubere Discovery-Logik glättet Monitoring den Stack entweder zu einer einzigen undurchsichtigen Einheit oder zwingt Sie zu manueller Konfiguration.

Keine der beiden Optionen skaliert.

Die neue Discovery-Regel schließt genau diese Lücke. Statt den Stack als Monolith zu behandeln, kann Zabbix jetzt dynamisch Chassis-Mitglieder erkennen und granulare Daten abrufen: Status, Rolle (Master, Linecard, Backup), Firmware-Version, MAC-Adresse und mehr. Das ist der Unterschied zwischen oberflächlichem Monitoring und echter operativer Sichtbarkeit.

Reden wir kurz über Rollen. In einem Virtual Chassis ist der Master nicht nur ein weiteres Mitglied—er ist der Anker der Control Plane. Fällt er aus und ein Backup übernimmt, wollen Sie das wissen. Nicht nur, dass der Stack "up" ist, sondern dass die Führung gewechselt hat. Stille Failovers sind großartig für die Verfügbarkeit. Sie sind furchtbar für unbemerkte Instabilität.

Mit Discovery-getriebenem Monitoring werden diese Übergänge sichtbar.

Und Firmware-Tracking? Das ist riesig. Gemischte Firmware in einem Stack kann zu subtilen, üblen Problemen führen. Firmware-Sichtbarkeit pro Mitglied innerhalb von Zabbix macht das Lifecycle-Management sauberer. Sie müssen sich nicht per SSH in jedes Mitglied einloggen, um Versionen zu bestätigen. Es steht direkt in Ihren Monitoring-Daten.

Die Tatsache, dass dies über EX2300-, EX3400- und EX3300-Modelle hinweg getestet wurde, ist beruhigend. Diese Modelle spannen unterschiedliche Generationen und Leistungsklassen. Wenn sich die Vorlage über sie hinweg konsistent verhält, deutet das darauf hin, dass die Discovery-Logik solide ist—nicht eng auf ein einzelnes Labor-Gerät zugeschnitten.

Es gibt auch etwas still Befriedigendes daran, ein verwaistes Repository zu modernisieren. Acht Jahre im Networking sind eine Ewigkeit. SNMP-Strukturen entwickeln sich weiter. Best Practices verschieben sich. Zabbix selbst hat sich erheblich weiterentwickelt. Eine alte Vorlage ohne Anpassungen gegen Zabbix 7.x laufen zu lassen, fühlt sich oft an, als würde man versuchen, ein VGA-Kabel in einen USB-C-Port zu stecken. Mit genug Adaptern technisch möglich. Aber schmerzhaft.

Ein Fork schafft Luft zum Atmen. Sie können refaktorisieren. Item-Keys aufräumen. Preprocessing-Schritte an aktuelle Zabbix-Fähigkeiten anpassen. Low-Level-Discovery-Regeln einführen, ohne sich Sorgen zu machen, Legacy-Annahmen zu brechen.

Und diese Virtual-Chassis-Discovery-Regel? Das ist kein kosmetisches Feature. Sie verändert, wie Sie über das Monitoring gestapelter Switches denken. Statt "ein Host gleich ein Gerät" bewegen Sie sich in Richtung "ein Host gleich ein logischer Stack mit dynamischen internen Komponenten". Das ist ein weit genaueres Modell dafür, wie EX-Deployments tatsächlich funktionieren.

Es öffnet auch Türen. Sobald Sie Chassis-Mitglieder dynamisch erkennen, können Sie die Logik erweitern. Temperatursensoren pro Mitglied. Netzteilstatus. Uplink-Verteilung. Plötzlich sammelt Ihre Vorlage nicht nur Statistiken—sie bildet die interne Topologie des Stacks ab.

Es gibt hier auch ein tieferes Thema. Community-Vorlagen werden oft für Einzelgerät-Szenarien gebaut. Aber Produktionsumgebungen bleiben selten bei einem einzelnen Gerät. Stacking, Clustering, Hochverfügbarkeit—all das erschwert das Monitoring. Vorlagen, die diese Muster verstehen, sind selten und wertvoll.

Einen Pull Request beim ursprünglichen Repository einzureichen ist der richtige Schritt. Selbst wenn er nie gemergt wird, signalisiert er Absicht: Das ist nicht nur eine persönliche Anpassung. Es ist ein Versuch, etwas für alle Nützliches wiederzubeleben.

Und seien wir ehrlich—Juniper-EX-Switches sind überall. Access-Layer, Campus-Kerne, Distribution-Stacks. Sie richtig zu überwachen ist keine Option. Es ist fundamental. Wenn das Backup-Mitglied Ihres Stacks still ausfällt und Sie es erst bemerken, wenn der Master Wochen später abstürzt, ist das kein Tooling-Problem. Das ist eine Sichtbarkeitslücke.

Diese Vorlage will genau diese Lücke schließen.

Es ist auch eine Erinnerung daran, dass Netzwerk-Monitoring nicht bei Interface-Traffic-Grafiken aufhören sollte. Betriebszustand zählt. Rollenbewusstsein zählt. Hardware-Identität zählt. Wenn Sie ein Virtual Chassis wie eine Blackbox behandeln, verpassen Sie die Nuancen, die tatsächlich einen Ausfall vorhersagen.

Die besten Monitoring-Setups spiegeln die reale Architektur wider. Virtual Chassis ist kein Marketingbegriff—es ist eine strukturelle Realität. Vorlagen, die diese Realität anerkennen, fühlen sich weniger wie Hacks an und mehr wie Engineering.

Acht Jahre sind eine lange Zeit, in der ein Repository unangetastet bleibt. Aber manchmal bereitet genau diese Stille den Boden für ein stärkeres Comeback. Mit aktualisierter Kompatibilität, Tests an echten Modellen und eingebauter, sauberer Virtual-Chassis-Discovery fühlt sich dieser Fork weniger wie ein Patch an und mehr wie ein Neustart.

Und wenn Sie EX-Stacks auf Zabbix 7.x betreiben, ist dieser Neustart vielleicht genau das, worauf Ihr Monitoring-Stack gewartet hat.