Démarrer une session NETCONF

Le serveur NETCONF et l’application <hello> client émettent chacun un tag element pour spécifier les opérations ou fonctionnalités qu’ils supportent parmi les éléments définis dans la spécification NETCONF. L’élément <hello> de balise enferme <capabilities> l’élément et l’élément<session-id>, qui spécifie l’ID de processus UNIX (PID) du serveur NETCONF pour la session. Chaque élément <capabilities> définit <capability> une fonction prise en charge.

L’application client doit émettre l’étiquette <hello> avant tout autre élément lors de la session NETCONF et ne doit pas l’émettre plusieurs fois.

Chaque fonctionnalité définie dans la spécification NETCONF est <capability> représentée dans un élément par un nom de ressource uniforme (URN). Les fonctionnalités définies par les fournisseurs individuels sont représentées par des identificateurs de ressources (URL) uniformes, qui peuvent être des ADRESSES URL ou URL. Le protocole de gestion XML <hello> NETCONF émettra un élément similaire à l’échantillon de sortie suivant ( <capability> certains éléments apparaissent sur plusieurs lignes pour une plus grande flexibilité uniquement):

Les ADRESSES URL de l’élément <hello> indiquent les capacités prise en charge suivantes, qui ne sont pas exhaustives:

• urn:ietf:params:netconf:base:1.0—Le serveur NETCONF prend en charge les opérations et les éléments de base définis dans la spécification NETCONF de base.

• urn:ietf:params:netconf:capability:candidate:1.0—Le serveur NETCONF prend en charge les opérations dans une configuration de candidature.

• urn:ietf:params:netconf:capability:confirmed-commit:1.0—Le serveur NETCONF prend en charge les opérations de validation confirmées. Pour plus d’informations, consultez la validation de la configuration du candidat uniquement après confirmation à l’aide de NETCONF.

• urn:ietf:params:netconf:capability:validate:1.0—Le serveur NETCONF prend en charge l’opération de validation, qui vérifie le niveau de correction syntactic d’une configuration sans la valider réellement. Pour plus d’informations, consultez la vérification de la syntaxe de configuration du candidat à l’aide de NETCONF.

• urn:ietf:params:netconf:capability:url:1.0?protocol=http,ftp,file—Le serveur NETCONF accepte les données de configuration stockées dans un fichier. Il peut récupérer des fichiers à la fois depuis son système de fichiers local ( file indiqué par l’option dans l’URL) et depuis des machines distantes à l’aide du protocole HTTP (Hypertext Transfer Protocol) ou de FTP ( http ftp indiqué par les options et les options de l’URN). Pour plus d’informations, consultez les données de configuration de téléchargement et de format dans une session NETCONF.

• http://xml.juniper.net/netconf/junos/1.0—Le serveur NETCONF prend en charge les opérations définies dans l’API XML Junos pour la demande et la modification des informations opérationnelles (les éléments de balise de l’API XML de référence pour le développement opérationnel Junos). Le serveur NETCONF prend également en charge les opérations dans le protocole de gestion XML Junos pour la demande ou la modification des informations de configuration.

  Les applications client NETCONF doivent utiliser uniquement les opérations de protocole de gestion XML NETCONF natives et les extensions prise en charge disponibles dans le protocole de gestion XML Junos pour les fonctions de configuration. Les procédures de gestion des opérations de protocole XML Junos correspondantes et des opérations de protocole XML NETCONF ne sont pas forcément identiques. L’utilisation d’opérations de configuration de protocole XML Junos autres que les extensions documentées prise en charge peut entraîner des résultats imprévus.

• http://xml.juniper.net/dmi/system/1.0—Le serveur NETCONF prend en charge les opérations définies dans la spécification DMI (Device Management Interface).

Par défaut, le serveur NETCONF ne fait pas la publicité des modules YANG pris en charge dans l’échange des capacités NETCONF. Pour promouvoir les modules YANG pris en charge, configurez une ou plusieurs des instructions suivantes au niveau [edit system services netconf hello-message yang-module-capabilities] de la hiérarchie:

• advertise-custom-yang-modules— Faites la promotion des modules YANG tiers installés sur l’équipement.
• advertise-native-yang-modules— Faites la Junos OS des modules YANG natifs.
• advertise-standard-yang-modules— Faites la promotion des modules YANG standard pris en charge par l’équipement, par exemple les modules OpenConfig.

Pour se conformer à la spécification NETCONF, l’application client émettra également un élément pour définir les fonctionnalités <hello> qu’elle prend en charge. Il n’inclut pas l’élément <session-id> :

La session se poursuit lorsque l’application client envoie une demande au serveur NETCONF. Le serveur NETCONF n’émettra aucun élément après l’initialisation de la session, sauf en réponse aux demandes de l’application client.

L’échange d’éléments <hello> de balise permet à une application client et au serveur NETCONF de déterminer s’ils prendre en charge les mêmes fonctionnalités. En outre, nous recommandons à l’application client de déterminer la version du Junos OS qui s’exécute sur le serveur NETCONF. Une fois l’étiquette émise <hello> , l’application client émet <get-software-information> ce tag sur un <rpc> tag:

Le serveur NETCONF renvoie l’élément <software-information> de balise, qui joint <host-name> <product-name> <package-information> les éléments du tag et le tag, ainsi qu’un tag pour chaque module Junos OS réseau. <comment> <package-information> L’élément de balise de l’élément de balise spécifie le numéro de publication Junos OS (dans l’exemple suivant, 8.2 pour Junos OS Version 8.2) et la date de construction au format YYYYMMDD (année, mois, jour — 12 janvier 2007 dans l’exemple suivant). Certains éléments de balise apparaissent sur plusieurs lignes, pour une plus haute flexibilité uniquement:

En temps normal, la version est la même pour tous les modules Junos OS qui s’exécutent sur l’équipement (nous recommandons cette configuration pour des performances de routage prévisibles). Par conséquent, il suffit généralement de vérifier le numéro de version d’un seul module.

L’application client est chargée de déterminer comment gérer les différences de version ou de fonctionnalités. Pour des performances entièrement automatisées, inclure du code dans l’application client qui détermine s’il prend en charge les mêmes fonctionnalités et Junos OS version que le serveur NETCONF. Quelles options sont appropriées en cas de différences et implémentez la réponse correspondante:

• Ignorez les différences en matière de fonctionnalités Junos OS version et ne modifiez pas le comportement de l’application client pour accueillir le serveur NETCONF. Il ne s’agit pas nécessairement d’une différence entre le serveur Junos OS et le client. Il s’agit donc souvent d’une approche valide. De même, il s’agit d’une approche valide si les fonctionnalités que l’application client ne prend pas en charge sont des opérations toujours lancées par un client, telles que la validation d’une configuration et la validation confirmée. Dans ce cas, le client maintient la compatibilité en n’initpant pas l’opération.

• Modifier le comportement standard pour être compatible avec le serveur NETCONF. Si l’application client exécute une version ultérieure du Junos OS, par exemple, elle peut choisir d’émettre uniquement des éléments de balise XML NETCONF et Junos qui représentent les fonctionnalités logicielles disponibles dans la version du serveur NETCONF du Junos OS.

• Mettre fin à la session NETCONF et mettre fin à la connexion. Cela est approprié si vous décidez qu’il n’est pas pratique de s’adapter à la version ou aux capacités du serveur NETCONF. Pour obtenir des instructions, consultez la vidéo Mettre fin à une session NETCONF et fermer la connexion.