Commit der Kandidatenkonfiguration nur nach Bestätigung mithilfe von NETCONF

Wenn Sie die Kandidatenkonfiguration festlegen, können Sie eine explizite Bestätigung benötigen, damit der Commit dauerhaft wird. Der bestätigte Commit-Vorgang ist nützlich, um zu überprüfen, ob eine Konfigurationsänderung korrekt funktioniert, und verhindert den Verwaltungszugriff auf das Gerät nicht. Wenn die Änderung den Zugriff verhindert oder andere Fehler verursacht, stellt das automatische Rollback zur vorherigen Konfiguration den Zugriff wieder her, nachdem die Rollback-Frist abgelaufen ist. Wenn der Commit nicht innerhalb der angegebenen Zeit bestätigt wird, die standardmäßig 600 Sekunden (10 Minuten) beträgt, lädt das Gerät automatisch und committ (roll back zu) der zuvor festgelegten Konfiguration.

In einer NETCONF-Sitzung mit einem Gerät, auf dem Junos OS ausgeführt wird, um die Kandidatenkonfiguration zu bestätigen, aber eine explizite Bestätigung für den dauerhaften Commit erforderlich ist, schließt eine Clientanwendung das leere <confirmed/> Tag in das und <rpc> tag-Element <commit> ein.

Um eine Anzahl von Sekunden für die Rollback-Frist anzugeben, die sich von dem Standardwert von 600 Sekunden unterscheidet, enthält die Anwendung das <confirm-timeout> Tag-Element und gibt die Anzahl der Sekunden für die Verzögerung im Bereich von 1 bis 4.294.967.295 Sekunden an.

Hinweis:

Sie können keinen bestätigten Commit-Vorgang auf einer Instanz der kurzlebigen Konfigurationsdatenbank durchführen.

In jedem Fall bestätigt der NETCONF-Server, dass er die Kandidatenkonfiguration vorübergehend festgelegt hat, indem er das <ok/> Tag in .<rpc-reply>

Wenn der NETCONF-Server die Kandidatenkonfiguration nicht festlegen kann, schließt das <rpc-reply> Element stattdessen ein Element ein <rpc-error> , das den Grund für den Fehler erklärt. Die häufigsten Ursachen sind semantische oder syntaktische Fehler in der Kandidatenkonfiguration.

Um das Rollback auf eine Zeit später als die aktuelle Rollback-Frist hinauszuzögern, gibt die Clientanwendung das <confirmed/> Tag vor Ablauf der Frist erneut in einem <commit> Tag-Element aus. Optional enthält es das <confirm-timeout> Element, um anzugeben, wie lange das nächste Rollback verzögert werden soll. Lassen Sie dieses Tag-Element aus, um das Rollback standardmäßig 600 Sekunden (10 Minuten) zu verzögern. Die Clientanwendung kann das Rollback auf unbestimmte Zeit hinauszögern, indem sie das <confirmed/> Tag wiederholt auf diese Weise aussendet.

Um die Konfiguration dauerhaft zu festschreiben, gibt die Clientanwendung das Tag aus, das <commit/> in einem <rpc> Tag-Element eingeschlossen ist, bevor die Rollback-Frist verstreicht. Das Rollback wird abgebrochen und die Kandidatenkonfiguration sofort festgelegt, wie unter Commit the Candidate Configuration Using NETCONF beschrieben. Wenn die Kandidatenkonfiguration immer noch die gleiche ist wie die vorübergehend festgelegte Konfiguration, wird die vorübergehend festgelegte Konfiguration effektiv erneut bereitgestellt.

Wenn eine andere Anwendung das Tag-Element verwendet, um die <kill-session/> Sitzung dieser Anwendung zu beenden, während ein bestätigter Commit aussteht (diese Anwendung hat Änderungen vorgenommen, aber noch nicht bestätigt), stellt der NETCONF-Server, der diese Sitzung betreut, die Konfiguration in ihren Zustand zurück, bevor die bestätigte Commit-Anweisung ausgegeben wurde. Weitere Informationen zur Terminierung von Sitzungen finden Sie unter Beenden einer NETCONF-Sitzung.

Das folgende Beispiel zeigt, wie Sie die Kandidatenkonfiguration mit einer Rollback-Frist von 300 Sekunden festlegen.

Client-Anwendung

NETCONF-Server