Übersicht über das Generieren von persistenten oder vorübergehenden Konfigurationsänderungen mithilfe von Commit-Skripten
Commit-Skripte für Junos OS erzwingen benutzerdefinierte Konfigurationsregeln. Wenn eine Kandidatenkonfiguration Anweisungen enthält, von denen Sie entschieden haben, dass sie nicht in Ihrer Konfiguration enthalten sein dürfen, oder wenn die Kandidatenkonfiguration Anweisungen auslässt, die Sie als erforderlich erachtet haben, können Commit-Skripte die Konfiguration automatisch ändern und dadurch das Problem beheben.
Unterschiede zwischen persistenten und vorübergehenden Änderungen
Konfigurationsänderungen, die von Commit-Skripten vorgenommen werden, können persistent oder vorübergehend sein.
Eine dauerhafte Änderung verbleibt in der Kandidatenkonfiguration und wirkt sich auf Routing-Vorgänge aus, bis Sie sie explizit löschen, auch wenn Sie anschließend das Commit-Skript, das die Änderung generiert hat, entfernen oder deaktivieren und den commit Befehl erneut absetzen. Mit anderen Worten, das Entfernen des Commit-Skripts führt nicht dazu, dass eine dauerhafte Änderung aus der Konfiguration entfernt wird.
Eine vorübergehende Änderung wird dagegen in der Checkout-Konfiguration vorgenommen, nicht jedoch in der Kandidatenkonfiguration. Bei der Checkout-Konfiguration handelt es sich um die Konfigurationsdatenbank, die auf die standardmäßige Junos OS-Syntax überprüft wird, kurz bevor sie kopiert wird, um die aktive Konfiguration auf dem Gerät zu werden. Wenn Sie anschließend das Commit-Skript, das die Änderung vorgenommen hat, entfernen oder deaktivieren und den commit Befehl erneut absetzen, wird die Änderung nicht mehr an der Checkout-Konfiguration vorgenommen und wirkt sich daher nicht auf die aktive Konfiguration aus. Mit anderen Worten, durch das Entfernen des Commit-Skripts wird eine vorübergehende Änderung effektiv aus der Konfiguration entfernt.
Eine häufige Verwendung für vorübergehende Änderungen besteht darin, die Notwendigkeit zu beseitigen, bekannte Richtlinien wiederholt zu konfigurieren und anzuzeigen, sodass diese Richtlinien implizit erzwungen werden können. Wenn beispielsweise MPLS auf jeder Schnittstelle mit aktiviertem ISO-Protokoll (International Organization for Standardization) aktiviert werden muss, kann die Änderung vorübergehend sein, sodass die sich wiederholenden oder redundanten Konfigurationsdaten nicht in der Kandidatenkonfiguration übernommen oder angezeigt werden müssen. Darüber hinaus können Sie mit vorübergehenden Änderungen Skriptanweisungen schreiben, die die Änderung nur anwenden, wenn eine Reihe von Bedingungen erfüllt ist.
Persistente und vorübergehende Änderungen werden auf die gleiche Weise in die Konfiguration geladen, wie der load replace Konfigurationsmodusbefehl eine eingehende Konfiguration lädt. Beim Generieren einer persistenten oder vorübergehenden Änderung bewirkt das Hinzufügen des replace="replace" Attributs zu einem Konfigurationselement das gleiche Verhalten wie ein replace: Tag in einem load replace Vorgang.
Standardmäßig führt Junos OS die eingehende Konfiguration und die Kandidatenkonfiguration zusammen. Neue Anweisungen und Hierarchien werden hinzugefügt, und widersprüchliche Anweisungen werden überschrieben. Wenn Sie beim Generieren einer dauerhaften oder vorübergehenden Änderung das Attribut zu einem Konfigurationselement hinzufügen, ersetzt Junos OS das vorhandene Konfigurationselement durch das replace="replace" eingehende Konfigurationselement. Wenn das Attribut zu einem Konfigurationselement hinzugefügt wird, aber in der aktuellen Konfiguration kein Element mit demselben Namen vorhanden ist, wird das replace="replace" eingehende Konfigurationselement der Konfiguration hinzugefügt. Elemente, die nicht über das replace Attribut verfügen, werden in der Konfiguration zusammengeführt.
Persistente und vorübergehende Änderungen werden geladen, bevor die standardmäßigen Junos OS-Validierungsprüfungen durchgeführt werden. Das bedeutet, dass alle Konfigurationsänderungen, die von einem Commit-Skript vorgenommen werden, auf korrekte Syntax überprüft werden. Wenn die Syntax korrekt ist, wird die neue Konfiguration zur aktiven, betriebsbereiten Gerätekonfiguration.
Geschützte Elemente in der Konfigurationshierarchie können weder durch eine dauerhafte noch durch eine vorübergehende Änderung geändert oder gelöscht werden. Wenn ein Commit-Skript versucht, eine geschützte Anweisung oder Hierarchie zu ändern oder zu löschen, gibt Junos OS eine Warnung aus, dass die Änderung nicht vorgenommen werden kann, und fährt mit dem Commit fort.
Persistente und vorübergehende Änderungen weisen mehrere wichtige Unterschiede auf, wie in Tabelle 1 beschrieben.
Dauerhafte Änderungen |
Vorübergehende Änderungen |
|---|---|
Sie können eine dauerhafte Änderung in Commit-Skripten darstellen, indem Sie den SLAX- und XSLT-Commit-Skripte können mithilfe des |
Sie können eine vorübergehende Änderung in Commit-Skripten mit dem Parameter in Verbindung mit dem SLAX- und XSLT-Commit-Skripte können mithilfe des |
Sie können dauerhafte Änderungen verwenden, um beliebige Junos XML-Protokolloperationen auszuführen, z. B. Abschnitte der Konfiguration aktivieren, deaktivieren, löschen, einfügen (neu anordnen), kommentieren (kommentieren) und ersetzen. |
Wie bei dauerhaften Änderungen können Sie vorübergehende Änderungen verwenden, um beliebige Junos XML-Protokollvorgänge auszuführen. Einige Vorgänge des Junos XML-Protokolls sind jedoch bei vorübergehenden Änderungen, wie z. B. dem Generieren von Kommentaren und inaktiven Einstellungen, nicht sinnvoll. |
Persistente Änderungen werden immer während des Commit-Prozesses geladen, wenn keine Fehler durch Commit-Skripts oder durch die standardmäßige Gültigkeitsprüfung von Junos OS generiert werden. |
Damit vorübergehende Änderungen geladen werden können, müssen Sie die Wie dauerhafte Änderungen müssen auch vorübergehende Änderungen die standardmäßige Gültigkeitsprüfung von Junos OS bestehen. |
Persistente Änderungen funktionieren wie der Wenn Sie beim Generieren einer dauerhaften Änderung das Attribut zu einem Konfigurationselement hinzufügen, ersetzt Junos OS das vorhandene Element in der Kandidatenkonfiguration durch das |
Vorübergehende Änderungen funktionieren wie der Wenn Sie beim Generieren einer vorübergehenden Änderung das Attribut zu einem Konfigurationselement hinzufügen, ersetzt Junos OS das vorhandene Element in der Checkout-Konfiguration durch das Vorübergehende Änderungen werden nicht in die Kandidatenkonfiguration kopiert. Aus diesem Grund werden vorübergehende Änderungen nicht in der Konfiguration gespeichert, wenn das zugehörige Commit-Skript gelöscht oder deaktiviert wird. |
Nachdem eine dauerhafte Änderung festgeschrieben wurde, behandelt die Software sie wie eine Änderung, die Sie vornehmen, indem Sie die Kandidatenkonfiguration direkt bearbeiten und bestätigen. Nachdem die persistenten Änderungen in die Kandidatenkonfiguration kopiert wurden, werden sie in die Checkout-Konfiguration kopiert. Wenn die Änderungen die standardmäßigen Gültigkeitsprüfungen von Junos OS bestehen, werden die Änderungen an die Komponenten des Switches, des Routers oder des Sicherheitsgeräts weitergegeben. |
Jedes Mal, wenn eine vorübergehende Änderung vorgenommen wird, aktualisiert die Software die Checkout-Konfigurationsdatenbank. Nachdem die vorübergehenden Änderungen die standardmäßigen Gültigkeitsprüfungen von Junos OS bestanden haben, werden die Änderungen an die Gerätekomponenten weitergegeben. |
Nachdem Sie ein Skript übergeben haben, das die Generierung einer persistenten Änderung bewirkt, können Sie die persistente Änderung anzeigen, indem Sie den user@host# show Dieser Befehl zeigt nur persistente Änderungen an, keine vorübergehenden Änderungen. |
Nachdem Sie ein Skript übergeben haben, das die Generierung einer vorübergehenden Änderung bewirkt, können Sie die vorübergehende Änderung anzeigen, indem Sie den user@host# show | display commit-scripts Dieser Befehl zeigt sowohl persistente als auch vorübergehende Änderungen an. |
Persistente Änderungen müssen den Regeln für den benutzerdefinierten Konfigurationsentwurf entsprechen, die durch Commit-Skripte vorgegeben werden. Dies wird erst nach einem zweiten Commit-Vorgang deutlich, da persistente Änderungen nicht von den Commit-Skriptregeln für den aktuellen Commit-Vorgang ausgewertet werden. Der nachfolgende Commit-Vorgang schlägt fehl, wenn die persistenten Änderungen nicht den Regeln entsprechen, die von den Commit-Skripts auferlegt werden, die während des ersten Commit-Vorgangs konfiguriert wurden. |
Vorübergehende Änderungen werden nie von Ihren benutzerdefinierten Regeln getestet und müssen diesen auch nicht entsprechen. Dies wird durch die Reihenfolge der Vorgänge im Junos OS-Commit-Modell verursacht, die unter Commit-Skripts und Junos OS-Commit-Modell ausführlich erläutert wird. |
Eine dauerhafte Änderung bleibt in der Konfiguration auch dann erhalten, wenn Sie die Commit-Skriptanweisungen, die die Änderung generiert haben, löschen, deaktivieren oder deaktivieren. |
Wenn Sie die Commit-Skriptanweisungen, die eine vorübergehende Änderung generieren, löschen, deaktivieren oder deaktivieren, wird die Änderung nach dem nächsten Commit-Vorgang aus der Konfiguration entfernt. Kurz gesagt, wenn die zugehörigen Anweisungen oder das gesamte Commit-Skript entfernt werden, wird auch die vorübergehende Änderung entfernt. |
Wie bei der direkten CLI-Konfiguration können Sie eine dauerhafte Änderung entfernen, indem Sie zu einer vorherigen Konfiguration zurückkehren, die die Änderung nicht enthielt, und den |
Sie können eine vorübergehende Änderung nicht entfernen, indem Sie zu einer vorherigen Konfiguration zurückkehren. |
Sie können dauerhafte Änderungen direkt ändern, indem Sie die Konfiguration mithilfe der CLI bearbeiten. |
Sie können eine vorübergehende Änderung nicht direkt mithilfe der Junos OS CLI ändern oder löschen, da die Änderung nicht in der Kandidatenkonfiguration enthalten ist. Um den Inhalt einer vorübergehenden Änderung zu ändern, müssen Sie die Anweisungen im Commit-Skript ändern, das die vorübergehende Änderung generiert. |
Zusammenspiel von Konfigurationsänderungen und Konfigurationsgruppen
Jede Konfigurationsänderung, die Sie durch direktes Bearbeiten der Konfiguration über die Befehlszeilenschnittstelle (CLI) des Betriebssystems vornehmen können, kann auch von einem Commit-Skript als dauerhafte oder vorübergehende Änderung generiert werden. Dazu gehören Werte, die auf einer bestimmten Hierarchieebene oder in Konfigurationsgruppen angegeben sind. Wie bei der direkten CLI-Konfiguration überschreiben die im Ziel angegebenen Werte die von einer Konfigurationsgruppe geerbten Werte. Das Ziel ist die Anweisung, auf die Sie eine Konfigurationsgruppe anwenden, indem Sie die apply-groups Anweisung einschließen.
Wenn Sie persistente oder vorübergehende Änderungen als zu einer Konfigurationsgruppe gehörend definieren, werden die Konfigurationsgruppen in der Reihenfolge angewendet, die Sie in den apply-groups Anweisungen angeben, die Sie auf jeder Hierarchieebene außer der obersten Ebene einschließen können. Sie können die Vererbung einer Konfigurationsgruppe auch deaktivieren, indem Sie die apply-groups-except Anweisung auf einer beliebigen Hierarchieebene außer der obersten Ebene einfügen.
Jedes Commit-Skript überprüft die Ansicht nach der Vererbung der Konfiguration. Wenn eine Kandidatenkonfiguration eine Konfigurationsgruppe enthält, seien Sie vorsichtig, wenn Sie ein Commit-Skript verwenden, um die zugehörige Zielkonfiguration zu ändern, da dies die beabsichtigte Vererbung von der Konfigurationsgruppe ändern könnte.
Seien Sie auch vorsichtig, wenn Sie ein Commit-Skript verwenden, um eine Konfigurationsgruppe zu ändern, da die Konfigurationsgruppe möglicherweise von einer Anwendung generiert wird, die bei jedem Commit-Vorgang einen load replace Vorgang für die Gruppe ausführt.
Weitere Informationen zu Konfigurationsgruppen finden Sie im CLI-Benutzerhandbuch .
Tag-Elemente und Vorlagen zum Generieren von Änderungen
Um persistente oder vorübergehende Änderungen in Commit-Skripten zu generieren, können SLAX- und XSLT-Skripte die Vorlage und Python-Skripte die jcs:emit-change jcs.emit_change Methode verwenden. Die jcs:emit-change Vorlage und jcs.emit_change die Methode enthalten <change> implizit XML-Elemente <transient-change> . SLAX- und XSLT-Skripte können auch Änderungen generieren, indem sie die <change> Elemente und <transient-change> direkt in das Commit-Skript einfügen. Wenn Sie die jcs:emit-change Vorlage in SLAX- und XSLT-Skripten verwenden, können Sie den hierarchischen Kontext der Änderung einmal statt mehrmals festlegen. In Python-Skripts erfordert die Methode, dass die Konfigurationsdaten für die angeforderte Änderung den vollständigen Konfigurationspfad enthalten, der alle Ebenen der Konfigurationshierarchie darstellt, die jcs.emit_change als XML-Zeichenfolge formatiert sind.
Die <change> and-Elemente <transient-change> ähneln dem Vorgang, der <load-configuration> durch das Junos XML-Verwaltungsprotokoll definiert ist. Der mögliche Inhalt der <change> <transient-change> und-Elemente ist identisch mit dem Inhalt des Tag-Elements, das <configuration> im Junos XML-Protokollvorgang <load-configuration>verwendet wird. Ausführliche Informationen zu diesem <load-configuration> Element finden Sie im Entwicklerhandbuch für das Junos XML Management Protocol .