Ersetzen der Kandidatenkonfiguration mithilfe von NETCONF

Eine Methode zum Ersetzen der gesamten Kandidatenkonfiguration oder aller Daten in der offenen Konfigurationsdatenbank ist die Verwendung des Vorgangs<copy-config>. Das <target> Tag schließt das <candidate/> Tag um, um anzugeben, dass die neuen Konfigurationsdaten entweder die Daten in der offenen Konfigurationsdatenbank ersetzen (wenn die Clientanwendung vor der Ausführung des Vorgangs den <copy-config> Junos XML-Protokollvorgang <open-configuration> ausgestellt hat) oder wenn keine offene Datenbank vorhanden ist, die Daten in der Kandidatenkonfiguration.

Das <source> Element schließt das <url> Element um, das den Dateinamen angibt, der die neuen Konfigurationsdaten enthält. Wenn die Konfigurationsdaten als Junos XML-Tagelemente formatiert sind, legen Sie das <url> format Attribut auf xml das Attribut fest oder lassen es aus. Wenn die Konfigurationsdaten als CLI-Konfigurationsanweisungen formatiert werden, legen Sie das <url> format-Attribut auf text.

Eine weitere Methode zum Ersetzen der gesamten Kandidatenkonfiguration oder aller Daten in der offenen Konfigurationsdatenbank besteht darin, den <edit-config> Vorgang zu verwenden und den Konfigurationsbearbeitungsmodus als globale Variable festzulegenreplace. Die Anwendung enthält das <default-operation> Tag-Element mit dem Wert replace im <edit-config> Tag-Element, wie unter Festlegen des Konfigurationsmodus für die Bearbeitung in einer NETCONF-Sitzung beschrieben. Das <target> Tag schließt das <candidate/> Tag um, um anzugeben, dass die neuen Konfigurationsdaten entweder die Daten in der offenen Konfigurationsdatenbank ersetzen (wenn die Clientanwendung vor der Ausführung des Vorgangs den <edit-config> Junos XML-Protokollvorgang <open-configuration> ausgestellt hat) oder wenn keine offene Datenbank vorhanden ist, die Daten in der Kandidatenkonfiguration.

Um die neuen Konfigurationsdaten anzugeben, enthält die Anwendung ein Oder ein <config> Tag-Element, das die Daten enthält, oder sie enthält ein <url> Tag-Element, das die Datei mit den Daten benennt, wie in Upload and Format Configuration Data in einer NETCONF-Sitzung<config-text> beschrieben.

Geräte mit Junos OS speichern je nach Plattform eine Kopie der zuletzt vorgenommenen Konfiguration und bis zu 49 vorherige Konfigurationen. Sie können zu jeder der gespeicherten Konfigurationen zurückkehren. Dies ist nützlich, wenn Konfigurationsänderungen zu unerwünschten Ergebnissen führen und Sie zu einer bekannten Arbeitskonfiguration zurückkehren möchten. Das Rollback der Konfiguration ähnelt dem Prozess für Konfigurationsänderungen auf dem Gerät, aber anstatt Konfigurationsdaten zu laden, führen Sie ein Rollback durch, bei dem die gesamte Kandidatenkonfiguration durch eine zuvor festgelegte Konfiguration ersetzt wird.

Ab Junos OS Version 18.1R1 kann eine NETCONF-Anwendung den <rollback-config> RPC ausführen, um entweder die Kandidatenkonfiguration oder alle Daten in der offenen Konfigurationsdatenbank durch eine zuvor festgelegte Konfiguration zu ersetzen. Um die Konfiguration zurück zu setzen, emittiert die Anwendung das <rollback-config> Element mit dem <index> untergeordneten Element, das den numerischen Index der vorherigen Konfiguration zum Laden angibt. Gültige Werte sind 0 (Null, für die zuletzt festgelegte Konfiguration) bis eines weniger als die Anzahl der gespeicherten vorherigen Konfigurationen (maximal 49).

Hinweis:

NETCONF-Anwendungen können auch den Junos XML-Protokollvorgang <load-configuration> mit dem rollback Attribut verwenden, um die Konfiguration zurück zu setzen.

Zum Laden der Konfiguration mit einem Rollback-Index von 1 gibt die Clientanwendung beispielsweise den folgenden RPC aus:

Der NETCONF-Server zeigt an, dass der Load-Vorgang erfolgreich war, indem er die <rollback-config-results> und-Elemente <ok/> in seiner RPC-Antwort zurückgibt.

Wenn der Lastvorgang erfolgreich ist, muss die Clientanwendung die Konfiguration festlegen, um sie zur aktiven Konfiguration auf dem Gerät zu machen. Wenn beim Laden der Rollback-Konfiguration ein Fehler auftritt, gibt er ein <rpc-error> Element mit Informationen über den Fehler zurück.

Mit einer Wiederherstellungskonfiguration können Sie eine bekannte Arbeitskonfiguration oder eine Konfiguration mit einem bekannten Zustand definieren, den Sie jederzeit wiederherstellen können. Sie verwenden die Wiederherstellungskonfiguration, wenn Sie zu einer bekannten Konfiguration wiederherstellen müssen, oder als letzter Ausweg, wenn die Gerätekonfiguration und die Backup-Konfigurationsdateien ohne Reparatur beschädigt werden. Wenn Sie eine Wiederherstellungskonfiguration erstellen, speichert das Gerät die zuletzt festgelegte Konfiguration als Wiederherstellungskonfiguration.

Ab Junos OS Version 18.1R1 kann eine NETCONF-Anwendung den <rollback-config> RPC ausführen, um entweder die Kandidatenkonfiguration oder alle Daten in der offenen Konfigurationsdatenbank durch die Wiederherstellungskonfiguration des Geräts zu ersetzen. Zum Laden der Wiederherstellungskonfiguration gibt die Anwendung das Element und <rescue/> das <rollback-config> untergeordnete Tag aus. Die Wiederherstellungskonfiguration muss auf dem Gerät vorhanden sein, bevor Sie sie laden können.

Hinweis:

NETCONF-Anwendungen können auch den Junos XML-Protokollvorgang <load-configuration> mit dem rescue Attribut verwenden, um die Wiederherstellungskonfiguration zu laden.

Zum Laden der Wiederherstellungskonfiguration gibt die Clientanwendung beispielsweise den folgenden RPC aus:

Der NETCONF-Server zeigt an, dass der Load-Vorgang erfolgreich war, indem er die <rollback-config-results> und-Elemente <ok/> in seiner RPC-Antwort zurückgibt.

Wenn der Lastvorgang erfolgreich ist, muss die Clientanwendung die Konfiguration festlegen, um sie zur aktiven Konfiguration auf dem Gerät zu machen. Wenn die Wiederherstellungskonfiguration nicht vorhanden ist oder der Server beim Laden der Konfigurationsdaten auf einen anderen Fehler stößt, gibt er ein <rpc-error> Element mit Informationen über den Fehler zurück.