Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Comprendre le protocole de gestion XML NETCONF

Découvrez le protocole de configuration réseau (NETCONF) et les avantages de son utilisation pour gérer vos périphériques réseau.

Avantages de NETCONF

  • NETCONF est un protocole standardisé qui a été développé spécifiquement pour la gestion des équipements réseau.

  • NETCONF utilise des sessions sécurisées et orientées connexion qui assurent l’authentification, l’intégrité des données et la confidentialité.

  • NETCONF est indépendant des fournisseurs, vous pouvez donc utiliser les mêmes opérations de base NETCONF pour gérer les périphériques de différents fournisseurs.

Présentation du protocole de gestion XML NETCONF

Le protocole de gestion XML NETCONF est un protocole standardisé spécialement conçu pour la communication avec les périphériques réseau et leur gestion. NETCONF utilise un modèle client/serveur et une communication basée sur l’appel de procédure à distance (RPC). Un client NETCONF établit une connexion et une session NETCONF avec un serveur NETCONF et exécute des opérations sur l’équipement. Les équipements Junos intègrent le serveur NETCONF dans le système d’exploitation, de sorte que le serveur n’apparaît pas comme une entrée distincte dans les listes de processus.

NETCONF utilise un codage de données XML pour les RPC et les données de configuration. Le protocole NETCONF définit des opérations de base équivalentes aux commandes du mode de configuration de la CLI. Les applications clientes utilisent les opérations de protocole pour afficher, modifier et valider les données de configuration (entre autres opérations), tout comme les administrateurs utilisent les commandes du mode de configuration de la CLI pour effectuer ces opérations. Au sein d’une session NETCONF, les applications clientes peuvent également exécuter des RPC équivalents à des commandes en mode opérationnel de Junos OS.

Conceptuellement, NETCONF peut être divisé en 4 couches. Le Tableau 1 décrit les couches.

de
Tableau 1 : couches NETCONF
Descriptionla couche NETCONF

Transports

La couche de transport facilite la création de sessions entre le client et le serveur à l’aide de différents protocoles.

Messages

La couche messages est un mécanisme de tramage indépendant du transport pour coder les RPC et les notifications. Les balises incluent :
  • <rpc>: encapsule les RPC envoyés au serveur NETCONF.

  • <rpc-reply>: encapsule les réponses RPC reçues du serveur NETCONF, qui peuvent inclure des données, <ok/> des balises, des erreurs et des avertissements.

  • <notification>: encapsule les messages de notification, qui sont des messages unidirectionnels que le serveur NETCONF envoie de manière asynchrone aux clients NETCONF qui s’abonnent aux notifications. Pour plus d’informations sur les notifications d’événements NETCONF, consultez Notifications d’événements NETCONF.

Opérations

La couche opérations définit les opérations de protocole que vous pouvez effectuer sur un équipement réseau. Les opérations comprennent les opérations de protocole de base, par exemple, <get-config>, <edit-config>et <commit>, ainsi que les opérations spécifiques au fournisseur. Une application cliente appelle les opérations en tant que RPC et fournit des paramètres codés en XML. Pour plus d’informations sur des opérations spécifiques, reportez-vous à la section Opérations et attributs du protocole NETCONF de ce guide.

Contenu

La couche de contenu contient les charges utiles de requête et de réponse RPC au format XML. Cette couche définit les données de configuration et les données de notification.

La communication entre le serveur NETCONF et une application cliente est basée sur des sessions. Le serveur et le client établissent explicitement une connexion et une session avant d’échanger des données. Tel que défini par la couche transport, NETCONF peut utiliser n’importe quel protocole de transport sécurisé répondant aux exigences nécessaires. Les équipements Junos prennent en charge les sessions NETCONF sur SSH, SSH sortant, TLS et HTTPS sortant, ainsi que les sessions Call Home NETCONF sur SSH sortant.

Chaque session NETCONF commence par un établissement de liaison, dans lequel le serveur et le client échangent <hello> des balises qui entourent leurs capacités NETCONF prises en charge. Au sein d’une session NETCONF, le client et le serveur échangent des messages contenant des RPC, des réponses RPC ou des notifications. La couche opérations NETCONF définit les opérations de protocole qu’une application cliente peut utiliser pour gérer un équipement. La couche de contenu décrit les paramètres et les données codés inclus dans les RPC. NETCONF et l’API XML de Junos La présentation décrit la couche de contenu plus en détail. Une fois que l’application cliente a fini de faire des demandes, elle ferme la session et la connexion NETCONF.

Un client NETCONF envoie des RPC au serveur NETCONF pour demander des informations, exécuter des commandes opérationnelles ou modifier la configuration d’un équipement. Le serveur NETCONF traite les RPC et envoie des réponses RPC au client. Selon la demande, les réponses RPC renvoient les informations demandées ou indiquent le succès ou l’échec de l’opération demandée.

Pour plus d’informations sur NETCONF, consultez les RFC suivantes :

  • RFC 6241, Protocole de configuration réseau (NETCONF)

  • RFC 6242, Utilisation du protocole NETCONF sur Secure Shell (SSH)

Présentation de NETCONF et de l’API XML de Junos

L’API XML de Junos est une représentation XML des instructions de configuration et des commandes de mode opérationnel de Junos OS. L’API XLM de Junos définit un équivalent XML pour toutes les instructions de la hiérarchie de configuration de Junos OS et de nombreuses commandes que vous exécutez en mode opérationnel de la CLI. Chaque commande de mode opérationnel avec un équivalent XML Junos est mappée à un élément de balise de demande et, si nécessaire, à un élément de balise de réponse. Les balises de requête XML Junos sont équivalentes en fonction aux commandes de mode opérationnel correspondantes dans la CLI.

Les applications clientes NETCONF peuvent demander des informations, exécuter des commandes opérationnelles ou modifier la configuration d’un équipement Junos. L’application cliente encode la requête en éléments de balise NETCONF et API XML Junos et l’envoie au serveur NETCONF sur l’équipement. Le serveur NETCONF dirige la requête vers les modules logiciels appropriés, encode la réponse dans les éléments de balise NETCONF et XML Junos et renvoie le résultat à l’application cliente.

Lorsqu’un client NETCONF modifie la configuration de Junos OS, le contenu RPC inclut les données de configuration XML de Junos. Les clients NETCONF peuvent également envoyer des RPC opérationnels avec les balises de requête appropriées pour exécuter des commandes opérationnelles ou récupérer des informations. Le serveur renvoie la réponse à l’aide d’éléments d’API XML Junos inclus dans l’élément de balise de réponse correspondant.

Par exemple, pour demander des informations sur l’état des interfaces d’un équipement, une application cliente envoie la balise de demande d’API <get-interface-information/> XML Junos.

Le serveur NETCONF collecte les informations du processus d’interface et les renvoie dans l’élément de balise de réponse de l’API <interface-information> XML Junos.

Vous pouvez déterminer le contenu de l’API XML Junos de plusieurs façons. L’explorateur d’API XML de Juniper Networks vous permet de parcourir les éléments de l’API XML de Junos. Vous pouvez afficher les éléments de configuration et les balises de demande et de réponse opérationnelles prises en charge dans un système d’exploitation et une version donnés.

En outre, sur les équipements Junos, vous pouvez utiliser l’opérateur de canal (|) dans la CLI pour afficher le contenu de l’API XML Junos. Par exemple, pour récupérer la balise de demande opérationnelle d’une commande donnée, problème command | display xml rpc dans la CLI. L’exemple suivant montre que la balise request de la show interfaces commande est <get-interface-information>.

De même, pour récupérer les données de configuration au format XML, utilisez la show configuration | display xml commande.

Vous pouvez utiliser NETCONF et l’API XML de Junos pour gérer les équipements Junos. Vous pouvez écrire des applications clientes pour interagir avec le serveur NETCONF. Vous pouvez également utiliser NETCONF pour créer des interfaces utilisateur personnalisées pour la configuration, la récupération et l’affichage des informations, telles qu’une interface basée sur un navigateur Web.

Avantages de NETCONF et de l’API XML de Junos

NETCONF et l’API XML de Junos documentent toutes les options pour chaque requête opérationnelle Junos OS prise en charge et tous les éléments de chaque instruction de configuration de Junos OS. Les noms de balises indiquent clairement la fonction d’un élément dans une requête opérationnelle ou une instruction de configuration.

La combinaison de noms de balises significatifs et de règles structurelles dans une DTD facilite la compréhension du contenu et de la structure d’un ensemble de données balisées XML. Les balises NETCONF et Junos XML permettent aux applications clientes d’analyser facilement la sortie de l’appareil afin de trouver et d’afficher des informations spécifiques, comme décrit dans les sections suivantes.

Sortie de l’équipement d’analyse

L’exemple suivant illustre comment l’API XML de Junos facilite l’analyse de la sortie du périphérique et l’extraction des informations nécessaires. L’exemple compare des sorties ASCII et XML formatées d’un équipement exécutant Junos OS. La sortie ASCII formatée est la suivante :

La version correspondante avec balise XML est :

Lorsqu’une application cliente doit extraire une valeur spécifique d’une sortie ASCII formatée, elle doit s’appuyer sur l’emplacement de la valeur, exprimée de manière absolue ou par rapport aux étiquettes ou aux valeurs des champs adjacents. Supposons que l’application cliente souhaite extraire l’index de l’interface. Il peut utiliser un utilitaire de correspondance d’expressions régulières pour localiser des chaînes spécifiques, mais le nombre de chiffres dans l’index de l’interface n’est pas nécessairement prévisible. L’application cliente ne peut pas simplement lire un certain nombre de caractères après l’étiquette Interface index: . Au lieu de cela, il doit extraire tout ce qui se trouve entre l’étiquette et l’étiquette suivante, c’est-à-dire :

Un problème se pose si le format ou l’ordre de sortie change dans une version ultérieure de Junos OS. Par exemple, la sortie peut ajouter un champ après le numéro d’index Logical index de l’interface.

Une application qui extrait le numéro d’index de l’interface délimité par les Interface index: étiquettes et SNMP ifIndex obtient maintenant un résultat incorrect. Dans ce cas, vous devez mettre à jour l’application pour rechercher manuellement l’étiquette suivante à la place :

En revanche, la nature structurée de la sortie avec balise XML permet à une application cliente de récupérer l’index de l’interface en extrayant tout ce qui se trouve dans la balise d’ouverture <local-index> et la balise de fermeture </local-index> . L’application n’a pas besoin de s’appuyer sur la position d’un élément dans la chaîne de sortie. Par conséquent, le serveur NETCONF peut émettre les éléments de balise enfant dans n’importe quel ordre au sein de l’élément <physical-interface> . L’ajout d’un nouvel <logical-index> élément n’affecte pas la capacité d’une application à localiser l’élément <local-index> et à extraire son contenu.

Sortie du périphérique d’affichage

La sortie balisée XML est également plus facile à transformer en différents formats d’affichage. Par exemple, vous pouvez afficher différentes quantités de détails sur un composant d’appareil donné à différents moments. Lorsqu’un périphérique renvoie une sortie ASCII formatée, vous devez écrire des routines et des structures de données spéciales dans votre application pour extraire les informations nécessaires à un niveau de détail donné. En revanche, la structure inhérente à la sortie XML est une base idéale pour les propres structures d’un programme d’affichage. Vous pouvez utiliser la même routine d’extraction pour plusieurs niveaux de détail, en ignorant simplement les éléments de balise dont vous n’avez pas besoin lorsque vous affichez moins de détails.