Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Anfordern von Betriebsinformationen mithilfe von NETCONF

Innerhalb einer NETCONF-Sitzung kann eine Clientanwendung Informationen über den aktuellen Status eines Junos-Geräts anfordern. Um Betriebsinformationen anzufordern, gibt eine Clientanwendung das spezifische Anforderungs-Tag-Element von der Junos XML-API aus, das die gewünschten Informationen zurückgibt.

Tabelle 1 enthält Beispiele für Anforderungs-Tags, die dieselben Informationen wie der entsprechende CLI-Befehl anfordern.

"
Tabelle 1: Beispiele für Anforderungs-Tags und entsprechende CLI-Befehle
CLI-Befehl "Tag anfordern
<get-interface-information> show interfaces
<get-chassis-inventory> show chassis hardware
<get-system-inventory> show software information

Sie können das entsprechende Junos XML-Anforderungs-Tag auf verschiedene Weise ermitteln, darunter:

Mit dem folgenden Befehl wird z. B. das Anforderungstag angezeigt, das dem show interfaces Befehl entspricht:

Um einen RPC auszuführen, schließt die Clientanwendung ein Anforderungstag in ein Element ein <rpc> . Die Syntax hängt davon ab, ob der entsprechende CLI-Befehl Optionen enthält.

Die Clientanwendung kann die Formatierung der vom NETCONF-Server zurückgegebenen Informationen angeben. Durch Festlegen des optional-Attributs format im öffnenden operativen Anforderungstag kann eine Clientanwendung das Format der Antwort entweder als XML-Tagged-Format, d. h. als Standardformat, formatierten ASCII-Text, oder als JavaScript Object Notation (JSON) angeben. Weitere Informationen zum Angeben des Formats finden Sie unter Angeben des Ausgabeformats für Anforderungen an Betriebsinformationen in einer NETCONF-Sitzung.

Hinweis:

Bei der Anzeige von Betriebs- oder Konfigurationsdaten, die Zeichen außerhalb des 7-Bit-ASCII-Zeichensatzes enthalten, maskiert und codiert Junos OS diese Zeichen mit der entsprechenden UTF-8-Dezimalzeichenreferenz. Weitere Informationen finden Sie unter Funktionsweise der Zeichencodierung auf Geräten von Juniper Networks.

Wenn die Clientanwendung eine XML-Ausgabe anfordert, schließt der NETCONF-Server seine Antwort in das spezifische Antworttagelement ein, das dem Anforderungstagelement entspricht, das dann in ein <rpc-reply> Tagelement eingeschlossen wird.

Wenn z. B. die Clientanwendung den <get-interface-information> RPC sendet, gibt der NETCONF-Server das <interface-information> Antworttag zurück.

Im XML-Format enthält das öffnende Tag für jede operative Antwort das xmlns Attribut. Das Attribut definiert den XML-Namespace für die eingeschlossenen Tagelemente, die kein Namespace-Präfix haben (z. B junos:. ). Der Namespace gibt an, welche Junos XML-Dokumenttypdefinition (DTD) den Satz von Tag-Elementen in der Antwort definiert.

Die Junos XML-API definiert separate DTDs für Betriebsantworten von verschiedenen Softwaremodulen. Beispielsweise heißt die DTD für Schnittstelleninformationen junos-interface.dtd und die DTD für Chassisinformationen junos-chassis.dtd. Die Aufteilung in separate DTDs und XML-Namespaces bedeutet, dass ein gleichnamiges Tag-Element unterschiedliche Funktionen haben kann, je nachdem, in welcher DTD es definiert ist.

Der Namensraum ist eine URL des folgenden Formulars:

Wo:

  • release-code ist die Standardzeichenfolge, die die Junos OS-Version darstellt, die auf dem NETCONF-Servergerät ausgeführt wird.

  • category gibt die DTD an.

Wenn die Clientanwendung die Ausgabe in formatiertem ASCII-Text anfordert, schließt der NETCONF-Server seine Antwort in ein Tag-Element ein, das wiederum in ein <output> <rpc-reply> Tag eingeschlossen ist.

Wenn die Clientanwendung die Ausgabe im JSON-Format anfordert, schließt der NETCONF-Server die JSON-Daten in das <rpc-reply> tag-Element ein.