Anfordern von Konfigurationsdaten mit NETCONF
In einer NETCONF-Sitzung mit einem Gerät, auf dem Junos OS ausgeführt wird, schließt eine Clientanwendung die <get-config>Elemente , und <filter> tag in ein Tag-Element ein<rpc>, um Konfigurationsdaten für eine Routing-, <source>Switching- oder Sicherheitsplattform anzufordern. Durch das Einschließen des entsprechenden untergeordneten Tagelements in das <source> tag-Element fordert die Clientanwendung Informationen aus der aktiven Konfiguration oder aus der Kandidatenkonfiguration oder der offenen Konfigurationsdatenbank an. Durch das Einschließen der entsprechenden untergeordneten Tagelemente in das <filter> Tagelement kann die Anwendung die gesamte Konfiguration oder bestimmte Teile der Konfiguration anfordern.
<rpc>
<get-config>
<source>
<!-- tag specifying the source configuration -->
<( candidate | running )/>
</source>
<filter type="subtree">
<!-- tag elements representing the configuration elements to return -->
</filter>
</get-config>
</rpc>
]]>]]>
Das type="subtree" Attribut im öffnenden <filter> Tag gibt an, dass die Clientanwendung Junos XML-Tag-Elemente verwendet, um die Konfigurationselemente darzustellen, zu denen Informationen angefordert werden.
Wenn eine Clientanwendung den Junos XML-Protokollvorgang <open-configuration> ausgibt, um vor dem Ausführen des Vorgangs eine bestimmte Konfigurationsdatenbank zu öffnen, legen Sie die <get-config> Quelle so fest, dass <candidate/> die Konfigurationsdaten aus der geöffneten Konfigurationsdatenbank abgerufen werden. Andernfalls gibt der Server die Konfigurationsdaten aus der Kandidatenkonfiguration zurück.
Wenn die Clientanwendung die Kandidatenkonfiguration sperrt, bevor sie Anforderungen stellt, muss sie sie nach dem Senden der Leseanforderungen entsperren. Andere Benutzer und Anwendungen können die Konfiguration nicht ändern, solange sie gesperrt bleibt. Weitere Informationen finden Sie unter Sperren und Entsperren der Kandidatenkonfiguration mithilfe von NETCONF.
Der NETCONF-Server schließt seine Antwort in <rpc-reply>, <data>und <configuration> tag-Elemente ein. Das öffnende <configuration> Tag enthält Attribute, die den XML-Namespace für die eingeschlossenen Tagelemente angeben und angeben, wann die Konfiguration zuletzt geändert oder festgeschrieben wurde. Weitere Informationen zu den Attributen des <configuration> Tags finden Sie unter Angeben der Quelle für Konfigurationsinformationsanforderungen mithilfe von NETCONF.
<rpc-reply xmlns="URN" xmlns:junos="URL">
<data>
<configuration attributes>
<!-- JUNOS XML tag elements representing configuration elements -->
</configuration>
</data>
</rpc-reply>
]]>]]>
Wenn ein Junos XML-Tag-Element innerhalb eines <undocumented> Tag-Elements zurückgegeben wird, ist das entsprechende Konfigurationselement nicht in den Junos OS-Konfigurationshandbüchern dokumentiert und wird von Juniper Networks nicht offiziell unterstützt. In den meisten Fällen wird das eingeschlossene Element nur von Supportpersonal zum Debuggen verwendet. In einer kleineren Anzahl von Fällen wird das Element nicht mehr unterstützt oder in einen anderen Bereich der Konfigurationshierarchie verschoben, wird aber aus Gründen der Abwärtskompatibilität an der aktuellen Position angezeigt.
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.
Clientanwendungen können auch andere konfigurationsbezogene Informationen anfordern, z. B. eine XML-Schemadarstellung der Konfigurationshierarchie oder Informationen zu zuvor festgeschriebenen Konfigurationen.