Konfigurieren Sie RFC-konforme NETCONF-Sitzungen

Namespaces

Standardmäßig legt der NETCONF-Server den Standard-Namespace auf den NETCONF-Namespace im öffnende Tag der Antwort des Servers fest, und NETCONF-Tagnamen sind nicht qualifiziert. Zum Beispiel:

Wenn Sie die rfc-compliant Anweisung konfigurieren, definiert der NETCONF-Server keinen Standard-Namespace in seinen Antworten. Stattdessen enthält der Server eine Namespace-Deklaration für den NETCONF-Namespace, die an das nc Präfix gebunden ist, und qualifiziert alle NETCONF-Tags in seinen Antworten mit dem Präfix. Wenn Sie den Standard-Namespace in einer RPC-Anforderung auf den NETCONF-Namespace festlegen, verwirft der Server den Standard-Namespace und gibt seine Antwort nur mit dem erklärten Namespace aus, der an das nc Präfix gebunden ist.

Die folgende Beispielausgabe zeigt den Nachrichten- und Leistungsaustausch des <hello> NETCONF-Servers, wenn die rfc-compliant Anweisung konfiguriert ist. Das <hello> Tag enthält die xmlns:nc Deklaration, und alle NETCONF-Tags enthalten das nc Präfix.

Die folgende Ausgabe zeigt eine RPC-Beispielantwort, wenn die rfc-compliant Anweisung konfiguriert ist:

Wenn Sie die rfc-compliant Anweisung konfigurieren und Konfigurationsdaten in einer NETCONF-Sitzung anfordern, setzt der Server ab Junos OS Version 17.2R1 den Standard-Namespace für das <configuration> Element auf den gleichen Namespace wie im entsprechenden YANG-Modell.

Änderungen an <Get> and <Get-Config> Operations

Die rfc-compliant Anweisung wirkt sich auf die Antworten und <get-config> die <get> Serverantworten aus, wenn keine Konfigurationsdaten zurückgegeben werden können. Dies kann beispielsweise der Fall sein, wenn Sie einen Filter anwenden, um eine Teilmenge der Konfiguration zurückzugeben, und dieser Teil der Konfiguration ist leer.

Wenn Sie den <get> Vorgang ausführen <get-config> und keine Konfigurationsdaten in der angeforderten Hierarchie vorhanden sind, enthält die RPC-Antwort ein leeres <configuration> Element innerhalb des <data> Elements, wenn die rfc-compliant Anweisung nicht konfiguriert ist.

Wenn Sie den Vorgang oder <get-config> den <get> Vorgang ausführen und keine Konfigurationsdaten in der angeforderten Hierarchie vorhanden sind, gibt die RPC-Antwort, wenn die rfc-compliant Anweisung konfiguriert ist, ein leeres <data> Element zurück und lässt das <configuration> Element aus.

<rpc-error> Elemente mit einer Warnungsstufe für den Schweregrad in RPC-Antworten

Ab Junos OS Version 17.4R3, 18.2R2, 18.3R2 und 18.4R1 kann der NETCONF-Server, wenn Sie die rfc-compliant Anweisung konfigurieren, keine RPC-Antwort zurückgeben, die sowohl ein Element als auch ein <rpc-error> <ok/> Element enthält. Wenn der Vorgang erfolgreich ist, die Serverantwort aber zusätzlich zum Element ein oder <rpc-error> mehrere Elemente mit einer Warnungsstufe für den <ok/> Schweregrad enthält, werden die Warnungen entfallen. Darüber hinaus werden ab Junos OS Version 21.2R1 alle Warnungen, die während eines <commit> Vorgangs ausgelassen werden, zur Verfolgung in die Systemprotokolldatei umgeleitet.

In früheren Versionen oder wenn die rfc-compliant Anweisung nicht konfiguriert ist, gibt der NETCONF-Server möglicherweise eine RPC-Antwort aus, die sowohl ein <rpc-error> Element mit einem Warnungsschwere als auch ein <ok/> Element enthält. Beispielsweise kann ein Commit-Vorgang erfolgreich sein, geben aber eine Warnung wie in der folgenden NETCONF-Serverantwort zurück:

Wenn Sie die rfc-compliant Anweisung konfigurieren, wird die Warnung ausgelassen.

NETCONF Server Response to <commit> and <validate> Operations

Ab Junos OS Version 21.2R1 umfasst die Antwort des NETCONF-Servers auf <commit> den Betrieb, wenn Sie die rfc-compliant Anweisung konfigurieren, die folgenden Änderungen:

• Wenn bei einem erfolgreichen <commit> Vorgang eine Antwort mit einer oder mehreren Warnungen zurückgegeben wird, werden die Warnungen nicht nur in der Antwort, noch in der Systemprotokolldatei umgeleitet.

• Die NETCONF-Serverantwort emittiert das <source-daemon> Element als untergeordnetes Element <error-info> anstelle des <rpc-error> Elements.

• Wenn Sie die flatten-commit-results Anweisung auch auf [edit system services netconf] Hierarchieebene konfigurieren, gibt der NETCONF-Server nur ein <ok/> Element in <rpc-error> seiner Antwort aus und unterdrückt alle <commit-results> XML-Unterbäume.

Ab Junos OS Version 23.2R1 gibt der NETCONF-Server, wenn Sie die rfc-compliant Anweisung konfigurieren, nur ein Element oder <rpc-error> ein <ok/> Element als Reaktion auf <validate> den Betrieb aus. In früheren Versionen enthält die RPC-Antwort auch das <commit-results> Element.