Weblog

Additional CLI Commands

21.07.2025 4 Min. Lesezeit

Ein durchaus wertvolles, leider jedoch häufig mißverstandenes Feature von Juniper Mist, ist die Möglichkeit eigene Junos Kommandos an die generierte Konfiguration anzufügen, z.B. um Funktionen zu aktivieren, die noch nicht via UI bzw. API aufgerufen werden können.

Generell sollte man mit den Additional CLI Commands eher sparsam umgehen, weniger ist mehr, und so viel per UI bzw. API erledigen wie möglich. Sind eigene Kommandos unumgänglich, so sollte man sich wirklich Gedanken machen was zu erreichen ist, und wie man in der Zukunft damit umgeht. Mist wird konstant erweitert; was heute nur per Additional CLI Commands möglich ist, wird eventuell bereits beim nächsten Release als Bordmittel zur Verfügung gestellt.

Juniper selbst gibt Hilfestellung zum Handling:

Configure additional CLI commands in the Junos “set” format. Best practice: Use Junos “groups” configuration for all commands. Not using Junos groups statements can lead to inconsistencies in device configuration during addition/removal of the set commands.

Der erste Teil der Hilfestellung ist ja gut verständlich, aber was meinen die denn genau mit den “groups” und warum das helfen soll?

Beginnen wir mit einem einfachen Beispiel.

Juniper EX-Switche haben im Allgemeinen einen Management Ethernet Port, in Junos das fxp0 Interface. Wird das Interface nicht genutzt, etwa für ein Out-of-Band Management, so zeigt Junos einen Alarm an: FPC Management0 Ethernet Link Down.

{master:0}
user@switch&gt; show system alarms
1 alarms currently active
Alarm time Class Description
2025-07-21 18:25:30 UTC Major FPC Management0 Ethernet Link Down

In der Konfiguration, innerhalb der Chassis Hierarchie, kann konfiguriert werden, welchen Typ von Alarm der Management Ethernet Port im Falle eines DOWN Zustands auswerfen soll.

{master:0}[edit]
user@switch# set chassis alarm management-ethernet link-down ?
Possible completions:
ignore  Do not assert any alarm signals
red     Assert red system alarm
yellow  Assert yellow system alarm

Mein aktuelles Setup sieht kein OOB-Management vor, daher ist der Port bei meinen Switches ungenutzt und der Alarm per ignore dekonfiguriert.

Erwirkt ist diese Konfiguration über Additional CLI Commands in meinem Switch-Template.

Das funktioniert soweit, hat aber einen großen Nachteil: wenn ich in der Zukunft irgendwann diese Zeile entferne, was wird dann passieren?

Richtig - nichts. Additional CLI Commands werden der Konfiguration angehangen, es ist jedoch ein Trugschluß zu glauben die Konfiguration würde bei jeder Änderung komplett neu generiert. Setze ich heute mittels “set” ein Kommando ab, so wird dieses Kommando der Konfiguration von nun an angehangen bevor die candidate config committed wird. Ob in der running config diese Zeile bereits enthalten war oder nicht, spiel dabei keine Rolle.

Entferne ich morgen das “set” Kommando, so wird die Zeile aus der Chassis Hierarchie nicht entfernt, es wird nur aufgehört sie regelmäßig neu hinzuzufügen. Die Konfiguration innerhalb der Chassis Hierarchie wird von Mist nicht entfernt.

Möchte ich ein “set” entfernen, so muß ich zwingend ein “delete” in die Additional CLI Commands aufnehmen!

delete chassis alarm management-ethernet link-down ignore

Das “delete” kann ich dann ein paar Minuten später, wenn sicher gestellt wurde, daß jeder Switch aktualisiert wurde, wieder entfernen. Zur Sicherheit empfehle ich eine gute Stunde zu warten.

Was passiert aber nun, wenn ich das “delete” vergesse, das “set” aber entfernt habe. Meine running config weicht nun von dem ab, was Mist bei einem neuen Deployment generieren würde. Muß ich z.B. einen Switch austauschen, so entstehen Differenzen in der Konfiguration - Altlasten von morgen, und sicher nichts was einfach zu troubleshooten wird.

Best Practice

Ich habe mir angewöhnt, Additional CLI Commands generell in eine Gruppe zu packen. Erst das Ergebnis, dann die Erklärung:

delete groups wdein
# ignore unused management ethernet
set groups wdein chassis alarm management-ethernet link-down ignore
set apply-groups wdein

Funktional unterscheidet sich der Ansatz nur minimal. Anstatt der direkten Konfiguration innerhalb der Chassis Hierarchie erstelle ich eine Gruppe “wdein” und konfiguriere den Chassis-Anteil innerhalb der Gruppe. Da die Gruppe auf der obersten Ebene der Konfiguration angewendet wird, muß ich das Kommando nur minimal umformulieren.

Das Geheimnis liegt in der Soße!

Lösche die Gruppe “wdein”.
Erstelle die Gruppe neu, ausschließlich mit dem folgenden Inhalt.
Wende die Gruppe global an.

Was auf den ersten Schritt redundant aussieht und keinen offensichtlichen Mehrwert bringt, zeigt seine Stärke wenn Kommandos aus der Gruppe entfernt werden.

Durch Schritt 1, lösche die Gruppe, gefolgt von Schritt 2, erstelle die Gruppe mit definiertem Inhalt neu, wird sichergestellt, daß keine “set” Artefakte in der Konfiguration überbleiben. Jede entferne Zeile wird garantiert gelöscht und die Gruppe nur mit der aktuell gewünschten Konfiguration neu angelegt.

Eine schöne Lösung, wie ich finde.