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, und Virtual Chassis wurde in echten Deployments zum Standard. Die Vorlage dagegen ist im Jahr 2016 eingefroren.

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 überlebt Infrastruktur-Tooling genau so, indem jemand aufsteht und es in die Gegenwart zieht.

Die Vorlage wurde auf EX2300-, EX3400- und EX3300-Modellen mit Zabbix 7.0.4 im Labor getestet und mit echter Hardware validiert. Dieses Detail zählt, denn 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.

Das eigentliche Highlight-Feature ist aber 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, und 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.

Bei den Rollen wird das besonders deutlich. In einem Virtual Chassis ist der Master der Anker der Control Plane und damit mehr als nur ein weiteres Mitglied. Fällt er aus und ein Backup übernimmt, wollen Sie wissen, dass die Führung gewechselt hat, auch wenn der Stack weiter "up" ist. Stille Failovers sind großartig für die Verfügbarkeit und furchtbar, wenn sie unbemerkte Instabilität verdecken. Mit Discovery-getriebenem Monitoring werden diese Übergänge sichtbar.

Auch das Firmware-Tracking ist ein großer Gewinn. Gemischte Firmware in einem Stack kann zu subtilen, üblen Problemen führen, und 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 und nicht eng auf ein einzelnes Labor-Gerät zugeschnitten.

Es hat außerdem etwas Befriedigendes, ein verwaistes Repository zu modernisieren. Acht Jahre im Networking sind eine Ewigkeit: SNMP-Strukturen entwickeln sich weiter, Best Practices verschieben sich, und 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 ist das 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 und Low-Level-Discovery-Regeln einführen, ohne sich Sorgen zu machen, Legacy-Annahmen zu brechen.

Und die Virtual-Chassis-Discovery-Regel 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, etwa um Temperatursensoren pro Mitglied, Netzteilstatus und Uplink-Verteilung. Dann bildet Ihre Vorlage neben den Statistiken auch die interne Topologie des Stacks ab.

Dahinter steckt ein größeres Thema. Community-Vorlagen werden oft für Einzelgerät-Szenarien gebaut, aber Produktionsumgebungen bleiben selten bei einem einzelnen Gerät. Stacking, Clustering und Hochverfügbarkeit erschweren das Monitoring alle auf ihre Weise, und 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: Hier soll über eine persönliche Anpassung hinaus etwas für alle Nützliches wiederbelebt werden.

Juniper-EX-Switches sind außerdem überall, im Access-Layer, in Campus-Kernen und in Distribution-Stacks. Sie richtig zu überwachen ist deshalb fundamental. Wenn das Backup-Mitglied Ihres Stacks unbemerkt ausfällt und Sie es erst merken, wenn der Master Wochen später abstürzt, fehlt Ihnen Sichtbarkeit, und genau diese Lücke will die Vorlage schließen.

Es ist auch eine Erinnerung daran, dass Netzwerk-Monitoring nicht bei Interface-Traffic-Grafiken aufhören sollte. Betriebszustand, Rollenbewusstsein und Hardware-Identität zählen genauso. 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 eine strukturelle Realität und kein Marketingbegriff, und 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.