NETCONF-Beispielsitzung
In den folgenden Abschnitten wird die Reihenfolge der Tag-Elemente in einer NETCONF-Beispielsitzung mit einem Gerät mit Junos OS beschrieben. Die Clientanwendung beginnt mit dem Aufbau einer Verbindung zu einem NETCONF-Server.
Austausch von Initialisierungs-Tag-Elementen
Nachdem die Clientanwendung eine Verbindung zu einem NETCONF-Server hergestellt hat, werden die beiden Exchange-Tag-Elemente <hello> , wie im folgenden Beispiel dargestellt. Aus Gründen der Lesbarkeit platziert das Beispiel das Tag-Element der Clientanwendung <hello> unter dem NETCONF-Server. Die beiden Parteien können ihre <hello> Tag-Elemente tatsächlich gleichzeitig emittieren. Informationen zur ]]>]]> in diesem und den folgenden Beispielen verwendeten Zeichenreihenfolge finden Sie unter Generieren von wohlgeformten XML-Dokumenten. Eine ausführliche Diskussion über das <hello> Tag-Element finden Sie unter Austausch von <hello> Tag-Elementen.
Senden einer betrieblichen Anfrage
Die Clientanwendung emittiert das <get-chassis-inventory> Tag-Element, um Informationen über die Gehäusehardware des Geräts anzufordern. Der NETCONF-Server gibt die angeforderten Informationen im <chassis-inventory> Tag-Element zurück.
Sperren der Konfiguration
Die Clientanwendung bereitet sich dann darauf vor, eine Änderung in die Kandidatenkonfiguration zu integrieren, indem sie das <lock/> Tag aussendet, um zu verhindern, dass andere Benutzer oder Anwendungen gleichzeitig die Kandidatenkonfiguration ändern. Um zu bestätigen, dass die Kandidatenkonfiguration gesperrt ist, gibt der NETCONF-Server ein <ok/> Tag in einem Tag-Element zurück <rpc-reply> . Weitere Informationen zum Sperren der Konfiguration finden Sie unter Sperren und Entsperren der Kandidatenkonfiguration mit NETCONF.
Ändern der Konfiguration
Die Clientanwendung emittiert jetzt Tag-Elemente, um eine neue Junos OS-Anmeldeklasse zu erstellen, die [edit system login class] auf Hierarchieebene in der Kandidatenkonfiguration aufgerufen wirdnetwork-mgmt. Um zu bestätigen, dass der Ladevorgang erfolgreich war, gibt der NETCONF-Server ein <ok/> Tag in einem Tag-Element zurück<rpc-reply>.
Festlegen der Konfiguration
Die Clientanwendung legt dann die Kandidatenkonfiguration fest. Um zu bestätigen, dass der Commit-Vorgang erfolgreich war, gibt der NETCONF-Server ein <ok/> Tag in einem Tag-Element zurück <rpc-reply> . Weitere Informationen zum Commit-Vorgang finden Sie unter Commit the Candidate Configuration Using NETCONF.
Entsperren der Konfiguration
Die Client-Anwendung entsperrt (und schließt implizit) die Kandidatenkonfiguration. Um zu bestätigen, dass der Entsperrvorgang erfolgreich war, gibt der NETCONF-Server ein <ok/> Tag in einem Tag-Element zurück <rpc-reply> . Weitere Informationen zum Entsperren einer Konfiguration finden Sie unter Sperren und Entsperren der Kandidatenkonfiguration mit NETCONF.
Schließen der NETCONF-Sitzung
Die Clientanwendung schließt die NETCONF-Sitzung, indem sie das <close-session> Tag aussendet. Weitere Informationen zum Schließen der Sitzung finden Sie unter Beenden einer NETCONF-Sitzung und Schließen der Verbindung.
