Demander des données de configuration à l’aide de NETCONF
Dans une session NETCONF avec un équipement exécutant Junos OS, pour demander des données de configuration pour un routage, une commutation ou une plate-forme de sécurité, une application cliente enferme les <get-config>éléments , <source>et <filter> balise dans un élément de <rpc> balise. En incluant l’élément de balise enfant approprié dans l’élément <source> de balise, l’application cliente demande des informations à partir de la configuration active ou de la base de données de configuration ouverte du candidat. En incluant les éléments de balise enfant appropriés dans l’élément <filter> de balise, l’application peut demander la configuration entière ou des parties spécifiques de la configuration.
<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>
]]>]]>
L’attribut type="subtree" de la balise d’ouverture <filter> indique que l’application cliente utilise des éléments de balise XML Junos pour représenter les éléments de configuration sur lesquels elle demande des informations.
Si une application cliente exécute le protocole <open-configuration> Junos XML pour ouvrir une base de données de configuration spécifique avant d’exécuter l’opération <get-config> , la source <candidate/> récupère les données de configuration de la base de données de configuration ouverte. Sinon, le serveur renvoie les données de configuration de la configuration du candidat.
Si l’application client verrouille la configuration du candidat avant de faire des demandes, elle doit la déverrouiller après avoir fait ses demandes de lecture. Les autres utilisateurs et applications ne peuvent pas modifier la configuration tant qu’elle reste verrouillée. Pour plus d’informations, consultez verrouillage et déverrouillage de la configuration du candidat à l’aide de NETCONF.
Le serveur NETCONF contient sa réponse dans <rpc-reply>, <data>et <configuration> les éléments de balise . Elle inclut des attributs dans la balise d’ouverture <configuration> qui indiquent l’espace de noms XML pour les éléments de balise fermés et la date de la dernière modification ou de la dernière modification de la configuration. Pour plus d’informations sur les attributs de la <configuration> balise, voir Spécifier la source pour les demandes d’informations de configuration à l’aide de NETCONF.
<rpc-reply xmlns="URN" xmlns:junos="URL">
<data>
<configuration attributes>
<!-- JUNOS XML tag elements representing configuration elements -->
</configuration>
</data>
</rpc-reply>
]]>]]>
Si un élément de balise XML Junos est renvoyé dans un <undocumented> élément de balise, l’élément de configuration correspondant n’est pas documenté dans les guides de configuration Junos OS ni officiellement pris en charge par Juniper Networks. Le plus souvent, l’élément joint n’est utilisé que pour le débogage par le personnel d’assistance. Dans un plus petit nombre de cas, l’élément n’est plus pris en charge ou a été déplacé vers une autre zone de la hiérarchie de configuration, mais apparaît à l’emplacement actuel pour une rétrocompatibilité.
Lors de l’affichage des données opérationnelles ou de configuration qui contiennent des caractères en dehors du jeu de caractères ASCII 7 bits, Junos OS échappe et code ces caractères à l’aide de la référence décimale UTF-8 équivalente. Pour plus d’informations, consultez comment fonctionne l’encodage des caractères sur les équipements Juniper Networks.
Les applications clientes peuvent également demander d’autres informations de configuration, y compris une représentation de schéma XML de la hiérarchie de configuration ou des informations sur des configurations précédemment validées.