Bestätigen der Konfiguration

Die Gerätekonfiguration wird mithilfe eines Commit-Modells gespeichert – eine Kandidatenkonfiguration wird wie gewünscht geändert und dann an das System übergeben. Wenn eine Konfiguration festgeschrieben wird, prüft das Gerät die Konfiguration auf Syntaxfehler, und wenn keine Fehler gefunden werden, wird die Konfiguration gespeichert juniper.conf.gz und aktiviert. Die ehemals aktive Konfigurationsdatei wird als erste Rollback-Konfigurationsdatei (juniper.conf.1.gz) gespeichert, und alle anderen Rollback-Konfigurationsdateien werden um 1 erhöht. Wird z. B. auf juniper.conf.2.gzinkrementiert, juniper.conf.1.gzwas sie zur zweiten Rollback-Konfigurationsdatei macht. Auf dem Gerät können maximal 49 Rollback-Konfigurationen (mit den Nummern 1 bis 49) auf dem System gespeichert sein.

Auf dem Gerät befinden sich die aktuelle Konfigurationsdatei und die ersten drei Rollback-Dateien (juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3) im /config Verzeichnis. (Die restlichen Rollback-Dateien 4 bis 49 befinden sich in /var/db/config.)

Wenn die Wiederherstellungskonfigurationsdatei rescue.conf.gz vorhanden ist, befindet sich diese Datei ebenfalls im /config Verzeichnis. Die werkseitig voreingestellten Dateien befinden sich im /etc/config Verzeichnis.

Es gibt zwei Mechanismen, die verwendet werden, um die Konfigurationen zwischen Routing-Engines innerhalb eines Geräts weiterzugeben:

• Synchronisation: Überträgt eine Konfiguration von einer Routing-Engine an eine zweite Routing-Engine innerhalb desselben Gerätegehäuses.

  Verwenden Sie zum Synchronisieren von Konfigurationen den commit synchronize CLI-Befehl. Wenn eine der Routing-Engines gesperrt ist, schlägt die Synchronisierung fehl. Wenn die Synchronisierung aufgrund einer gesperrten Konfigurationsdatei fehlschlägt, können Sie den commit synchronize force Befehl verwenden. Mit diesem Befehl wird die Sperre außer Kraft gesetzt und die Konfigurationsdateien synchronisiert.

• Verteilung: Gibt eine Konfiguration über die Routingebene auf einem Gerät mit mehreren Chassis weiter. Die Verteilung erfolgt automatisch. Es steht kein Benutzerbefehl zur Steuerung des Verteilungsprozesses zur Verfügung. Wenn eine Konfiguration während einer Verteilung einer Konfiguration gesperrt wird, erhält die gesperrte Konfiguration die verteilte Konfigurationsdatei nicht, sodass die Synchronisierung fehlschlägt. Sie müssen die Sperre vor der Konfiguration aufheben und die Routingebenen neu synchronisieren.

  HINWEIS:

  Wenn Sie den commit synchronize force CLI-Befehl auf einer Multichassis-Plattform verwenden, wirkt sich die erzwungene Synchronisierung der Konfigurationsdateien nicht auf die Verteilung der Konfigurationsdatei über die Routingebene aus. Wenn eine Konfigurationsdatei auf einem Gerät gesperrt ist, das von dem Gerät entfernt ist, auf dem der Befehl ausgegeben wurde, schlägt die Synchronisierung auf dem Remotegerät fehl. Sie müssen die Sperre aufheben und den synchronization Befehl erneut ausführen.

Verwenden Sie den commit Befehl Konfigurationsmodus, um Änderungen an der Gerätekonfiguration in der Konfigurationsdatenbank zu speichern und die Konfiguration auf dem Gerät zu aktivieren. Sie können den commit Befehl von einer beliebigen Hierarchieebene aus ausgeben:

Bei der Eingabe des commit Befehls wird die Konfiguration zunächst auf Syntaxfehler (commit check) überprüft. Wenn die Syntax korrekt ist, wird die Konfiguration aktiviert und zur aktuellen, betriebsbereiten Gerätekonfiguration.

Ein Konfigurationscommit kann aus einem der folgenden Gründe fehlschlagen:

• Die Konfiguration enthält eine falsche Syntax, die dazu führt, dass die Commit-Prüfung fehlschlägt.

• Die Kandidatenkonfiguration, für die Sie einen Commit ausführen möchten, ist größer als 700 MB.

• Die Konfiguration wird von einem Benutzer gesperrt, der den configure exclusive Befehl eingegeben hat.

Wenn die Konfiguration Syntaxfehler enthält, wird in einer Meldung der Ort des Fehlers angegeben, und die Konfiguration ist nicht aktiviert. Die Fehlermeldung hat folgendes Format:

Zum Beispiel:

Sie müssen den Fehler korrigieren, bevor Sie die Konfiguration erneut bestätigen. Um schnell zu der Hierarchieebene zurückzukehren, auf der sich der Fehler befindet, kopieren Sie den Pfad aus der ersten Zeile des Fehlers, und fügen Sie ihn an der Eingabeaufforderung für den Konfigurationsmodus auf der [edit] Hierarchieebene ein.

Die nicht festgeschriebene Kandidatenkonfigurationsdatei ist /var/rundb/juniper.db. Es ist auf 700 MB begrenzt. Wenn der Commit mit einer Meldung configuration database size limit exceededfehlschlägt, zeigen Sie die Dateigröße im Konfigurationsmodus an, indem Sie den Befehl run file list /var/rundb detaileingeben. Sie können die Konfiguration vereinfachen und die Dateigröße reduzieren, indem Sie Konfigurationsgruppen mit Platzhaltern erstellen oder weniger spezifische Übereinstimmungsrichtlinien in Ihren Firewallfiltern definieren.

Wenn Sie einen Commit für eine Konfiguration ausführen, bestätigen Sie die gesamte Konfiguration in ihrer aktuellen Form.

Bis zu 32 Benutzer können sich gleichzeitig im Konfigurationsmodus befinden und Änderungen an der Konfiguration vornehmen. Alle Änderungen, die von allen Benutzern vorgenommen werden, sind für alle Benutzer sichtbar, die die Konfiguration bearbeiten – die Änderungen werden sichtbar, sobald der Benutzer die Eingabetaste am Ende eines Befehls drückt, der die Konfiguration ändert, z. B set. , editoder delete.

Wenn einer der Benutzer, der die Konfiguration bearbeitet, einen commit Befehl ausgibt, überprüft und aktiviert die CLI alle Änderungen durch alle Benutzer.

Wenn Sie mit dem Befehl in den configure private Konfigurationsmodus wechseln, hat jeder Benutzer eine private Kandidatenkonfiguration, die er etwas unabhängig von anderen Benutzern bearbeiten kann. Wenn Sie einen Commit für die Konfiguration ausführen, übernimmt die CLI nur Ihre eigenen Änderungen. Um Ihre Kopie der Konfiguration zu synchronisieren, nachdem andere Benutzer Änderungen übernommen haben, können Sie den update Befehl im Konfigurationsmodus ausführen. Bei einem Commit-Vorgang werden auch alle privaten Kandidatenkonfigurationen aktualisiert. Angenommen, Benutzer X und Benutzer Y befinden sich beide im configure private Modus und Benutzer X führt einen Commit für eine Konfigurationsänderung aus. Wenn Benutzer Y einen nachfolgenden Commit-Vorgang ausführt und dann die neue Konfiguration anzeigt, enthält die neue Konfiguration, die Benutzer Y sieht, die von Benutzer X vorgenommenen Änderungen.

Wenn Sie mit dem Befehl in den configure exclusive Konfigurationsmodus wechseln, sperren Sie die Kandidatenkonfiguration so lange, wie Sie im Konfigurationsmodus bleiben. Auf diese Weise können Sie Änderungen vornehmen, ohne dass andere Benutzer eingreifen. Andere Benutzer können in den Konfigurationsmodus wechseln und ihn beenden, aber sie können die Konfiguration nicht bestätigen. Dies gilt auch dann, wenn die anderen Benutzer vor der Eingabe des Befehls in den configure exclusive Konfigurationsmodus gewechselt sind. Angenommen, Benutzer X befindet sich bereits im configure private oder-Modus configure . Angenommen, Benutzer Y wechselt in den configure exclusive Modus. Benutzer X kann keine Änderungen an der Konfiguration übernehmen, selbst wenn Benutzer X diese Änderungen eingegeben hat, bevor sich Benutzer Y angemeldet hat. Wenn Benutzer Y den Modus verlässt configure exclusive , kann Benutzer X die in configure private oder configure -Modus vorgenommenen Änderungen übernehmen.

Der zweistufige Commit-Prozess ist dem einstufigen Prozess für zeitkritische Commits überlegen. Im einstufigen Prozess kann die Vorbereitungszeit je nach vorhandener Konfiguration auf dem Gerät variieren. Im zweistufigen Prozess werden die komplexen Vorbereitungsarbeiten effizienter abgewickelt.

Es werden Konfigurationsbefehle bereitgestellt, mit denen Sie den Konfigurationscache vorbereiten und die Konfiguration aktivieren können. Sie können die Geräte mit neuen Konfigurationen vorbereiten und sie genau zu den von Ihnen gewünschten Zeiten aktivieren.

Der commit prepare Befehl überprüft die Konfigurationen, und der commit activate Befehl aktiviert die Konfigurationen. Die Befehle verfügen über die folgenden Konfigurationsoptionen:

• and-quit

• no-synchronize

• peers-synchronize

• synchronize

Die commit prepare Befehle und commit activate sind nur für private, exklusive und freigegebene Commits verfügbar. Die Befehle gelten nicht für dynamische und flüchtige Modi. Diese Funktion gilt für Geräte mit mehreren Chassis, jedoch nicht für Batch-Commits.

Um diese Funktionalität mithilfe von NETCONF (Network Configuration Protocol) zu unterstützen, werden die folgenden neuen Remote Procedure Calls (RPCs) bereitgestellt:

• <commit-configuration>< prepare/></commit-configuration>

• <commit-configuration><activate/></commit-configuration>

• <clear-system-commit><prepared/></clear-system-commit>

Batch-Commit aggregiert oder führt mehrere Konfigurationsänderungen aus verschiedenen CLI-Sitzungen oder Benutzern zusammen und fügt sie einer Batch-Commit-Warteschlange hinzu. Ein auf dem Gerät ausgeführter Batch-Commit-Server übernimmt einen oder mehrere Aufträge aus der Batch-Commit-Warteschlange, wendet die Konfigurationsänderungen auf die freigegebene Konfigurationsdatenbank an und führt dann einen Commit für die Konfigurationsänderungen in einem einzigen Commit-Vorgang aus.

Batches werden vom Commit-Server basierend auf der Priorität des vom Benutzer angegebenen Batches oder dem Zeitpunkt, zu dem der Batchauftrag hinzugefügt wird, priorisiert. Wenn ein Batch-Commit abgeschlossen ist, werden die nächsten Konfigurationsänderungen aggregiert und in die Batch-Warteschlange für die nächste Sitzung des Batch-Commit-Vorgangs geladen. Batches werden so lange erstellt, bis keine Commit-Einträge mehr im Warteschlangenverzeichnis vorhanden sind.

Im Vergleich zum regulären Commit-Vorgang, bei dem alle Commits unabhängig voneinander sequenziell festgeschrieben werden, sparen Batch-Commits Zeit und Systemressourcen, indem sie mehrere kleine Konfigurationsänderungen in einem einzigen Commit-Vorgang ausführen.

Batch-Commits werden im [edit batch] Konfigurationsmodus ausgeführt. Die Eigenschaften des Commit-Servers können auf Hierarchieebene [edit system commit server] konfiguriert werden.

In diesem Beispiel wird gezeigt, wie die Eigenschaften des Batchcommitservers konfiguriert werden, um Batchcommitvorgänge zu verwalten.