NETCONF-Sitzung starten

Der NETCONF-Server und die Clientanwendung senden jeweils ein <hello> Tag-Element aus, um anzugeben, welche Vorgänge oder Funktionen sie von den in der NETCONF-Spezifikation definierten unterstützen. Das <hello> Tag-Element umschließt das <capabilities> Element und das <session-id> Element, das die UNIX-Prozess-ID (PID) des NETCONF-Servers für die Sitzung angibt. Innerhalb des <capabilities> Elements definiert jedes <capability> eine unterstützte Funktion.

Die Clientanwendung muss das <hello> Tag-Element vor jedem anderen Element während der NETCONF-Sitzung emittieren und darf es nicht mehr als einmal ausstrahlen.

Jede in der NETCONF-Spezifikation definierte Funktion wird in einem <capability> Element durch einen einheitlichen Ressourcennamen (URN) dargestellt. Die von einzelnen Anbietern definierten Funktionen werden durch einheitliche Ressourcenbezeichner (URIs) dargestellt, bei denen es sich um URNs oder URLs handelt. Das NETCONF XML-Verwaltungsprotokoll emittiert ein <hello> Element, das der folgenden Beispielausgabe ähnelt (einige <capability> Elemente werden nur zur Lesbarkeit in mehreren Zeilen angezeigt):

Die URIs im <hello> Element geben die folgenden unterstützten Funktionen an, was keine erschöpfende Liste ist:

• urn:ietf:params:netconf:base:1.0— Der NETCONF-Server unterstützt die grundlegenden Vorgänge und Elemente, die in der Basis-NETCONF-Spezifikation definiert sind.

• urn:ietf:params:netconf:capability:candidate:1.0— Der NETCONF-Server unterstützt Vorgänge in einer Kandidatenkonfiguration.

• urn:ietf:params:netconf:capability:confirmed-commit:1.0— Der NETCONF-Server unterstützt bestätigte Commit-Vorgänge. Weitere Informationen finden Sie unter Commit the Candidate Configuration only after confirmation using NETCONF.

• urn:ietf:params:netconf:capability:validate:1.0—Der NETCONF-Server unterstützt den Validierungsvorgang, der die syntaktische Korrektheit einer Konfiguration überprüft, ohne sie tatsächlich zu bestätigen. Weitere Informationen finden Sie unter Überprüfen der Kandidatenkonfigurationssyntax mit NETCONF.

• urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file— Der NETCONF-Server akzeptiert in einer Datei gespeicherte Konfigurationsdaten. Es kann Dateien sowohl aus seinem lokalen Dateisystem (die durch die file Option in der URN angegeben wird) als auch von Remote-Maschinen mithilfe von Hypertext Transfer Protocol (HTTP) oder FTP (angegeben durch die http und ftp optionen im URN) abrufen. Weitere Informationen finden Sie unter Hochladen und Formatieren von Konfigurationsdaten in einer NETCONF-Sitzung.

• http://xml.juniper.net/netconf/junos/1.0— Der NETCONF-Server unterstützt die Vorgänge, die in der Junos XML API für das Anfordern und Ändern von Betriebsinformationen definiert sind (die Tag-Elemente in der Junos XML API Operational Developer Reference). Der NETCONF-Server unterstützt auch Vorgänge im Junos XML-Managementprotokoll zum Anfordern oder Ändern von Konfigurationsinformationen.

  NETCONF-Clientanwendungen sollten nur native NETCONF XML-Managementprotokollvorgänge und unterstützte Erweiterungen verwenden, die im Junos XML-Verwaltungsprotokoll für Konfigurationsfunktionen verfügbar sind. Die Semantik der entsprechenden Junos XML-Protokolloperationen und NETCONF XML-Protokolloperationen muss nicht unbedingt identisch sein, sodass die Verwendung anderer Junos XML-Protokollkonfigurationsvorgänge als die dokumentierten unterstützten Erweiterungen zu unerwarteten Ergebnissen führen kann.

• http://xml.juniper.net/dmi/system/1.0— Der NETCONF-Server unterstützt die in der DMI-Spezifikation (Device Management Interface) definierten Vorgänge.

Standardmäßig kündigt der NETCONF-Server keine unterstützten YANG-Module im NETCONF-Funktionsaustausch an. Um unterstützte YANG-Module anzukündigen, konfigurieren Sie eine oder mehrere der folgenden Anweisungen auf [edit system services netconf hello-message yang-module-capabilities] Hierarchieebene:

• advertise-custom-yang-modules— Bewerben Sie auf dem Gerät installierte YANG-Module von Drittanbietern.
• advertise-native-yang-modules— Bewerben Sie junos OS-native YANG-Module.
• advertise-standard-yang-modules— Bewerben Sie standard-YANG-Module, die vom Gerät unterstützt werden, z. B. OpenConfig-Module.

Um der NETCONF-Spezifikation zu entsprechen, gibt die Clientanwendung auch ein Element aus <hello> , um die von ihnen unterstützten Funktionen zu definieren. Es umfasst nicht das <session-id> Element:

Die Sitzung wird fortgesetzt, wenn die Clientanwendung eine Anfrage an den NETCONF-Server sendet. Der NETCONF-Server emittiert nach der Sitzungsinitialisierung keine Elemente, außer als Antwort auf Die Anforderungen der Clientanwendung.

Durch den Austausch von <hello> Tagelementen können eine Clientanwendung und der NETCONF-Server feststellen, ob sie die gleichen Funktionen unterstützen. Darüber hinaus empfehlen wir, dass die Clientanwendung die Version des Junos OS bestimmt, die auf dem NETCONF-Server ausgeführt wird. Nach dem Senden des <hello> Tags gibt die Clientanwendung das <get-software-information> Tag-Element in einem Tag-Element aus <rpc> :

Der NETCONF-Server gibt das <software-information> Tag-Element zurück, das die <host-name> Tag-Elemente und <product-name> ein <package-information> Tag-Element für jedes Junos OS-Modul umschließt. Das <comment> Tag-Element innerhalb des <package-information> Tag-Elements gibt die Versionsnummer von Junos OS an (im folgenden Beispiel 8.2 für Junos OS Release 8.2) und das Builddatum im Format YYYYMMDD (Jahr, Monat, Tag – im folgenden Beispiel 12. Januar 2007). Einige Tag-Elemente werden in mehreren Zeilen angezeigt, nur aus Gründen der Lesbarkeit:

Normalerweise ist die Version für alle Junos OS-Module, die auf dem Gerät ausgeführt werden, gleich (wir empfehlen diese Konfiguration für eine vorhersehbare Routing-Leistung). Daher ist es in der Regel ausreichend, die Versionsnummer nur eines Moduls zu überprüfen.

Die Client-Anwendung ist dafür verantwortlich, zu bestimmen, wie mit Abweichungen in Version oder Funktionen umgegangen werden soll. Fügen Sie für eine vollständig automatisierte Leistung Code in die Clientanwendung ein, der bestimmt, ob sie die gleichen Funktionen und Junos OS-Version wie der NETCONF-Server unterstützt. Entscheiden Sie, welche der folgenden Optionen bei Abweichungen geeignet ist, und implementieren Sie die entsprechende Antwort:

• Ignorieren Sie unterschiede in den Funktionen und der Junos OS-Version, und ändern Sie das Verhalten der Clientanwendung nicht, um den NETCONF-Server zu unterstützen. Ein Unterschied zwischen Junos OS-Versionen macht Server und Client nicht unbedingt inkompatibel, daher ist dies oft ein gültiger Ansatz. Ebenso ist es ein gültiger Ansatz, wenn die Funktionen, die die Clientanwendung nicht unterstützt, Vorgänge sind, die immer von einem Client initiiert werden, wie z. B. Validierung einer Konfiguration und bestätigten Commit. In diesem Fall behält der Client die Kompatibilität, indem er den Vorgang nicht initiiert.

• Ändern Sie das Standardverhalten, um mit dem NETCONF-Server kompatibel zu sein. Wenn auf der Clientanwendung z. B. eine höhere Version von Junos OS ausgeführt wird, kann sie auswählen, dass nur NETCONF- und Junos XML-Tag-Elemente emittiert werden, die die Softwarefunktionen darstellen, die in der Version des NETCONF-Servers von Junos OS verfügbar sind.

• Beenden Sie die NETCONF-Sitzung und beenden Sie die Verbindung. Dies ist angebracht, wenn Sie entscheiden, dass es nicht praktikabel ist, die Version oder die Funktionen des NETCONF-Servers unterzubringen. Anweisungen finden Sie unter Beenden einer NETCONF-Sitzung und Schließen der Verbindung.