Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Exemple : utiliser un RPC YANG personnalisé pour récupérer des informations opérationnelles sur les équipements Junos

Vous pouvez ajouter des modèles de données YANG qui définissent des RPC personnalisés sur les équipements Junos. La création de RPC personnalisés vous permet de définir avec précision les paramètres et les opérations d’entrée, ainsi que les champs de sortie et la mise en forme de vos tâches opérationnelles spécifiques sur ces équipements. Cet exemple présente un RPC personnalisé et un script d’action qui récupèrent les informations opérationnelles de l’équipement et affichent une sortie CLI personnalisée.

Le RPC est ajouté au schéma Junos OS sur l’équipement. Lorsque le RPC est exécuté dans l’interface de ligne de commande, il imprime le nom et le statut opérationnel des interfaces physiques demandées.

Exigences

Cet exemple utilise les composants matériels et logiciels suivants :

  • Équipement exécutant Junos OS version 17.3R1 ou ultérieure prenant en charge le chargement de modèles de données YANG personnalisés.

Présentation du RPC et du script d’action

Le module YANG de cet exemple définit un RPC personnalisé pour renvoyer le nom et le statut opérationnel de certaines interfaces physiques. Le module rpc-interface-status YANG est enregistré dans le fichier rpc-interface-status.yang . Le module importe les modules d’extension Junos OS, qui fournissent les extensions requises pour exécuter des RPC personnalisés sur l’équipement et personnaliser la sortie CLI.

Le module définit le get-interface-status RPC. La <get-interface-status> balise request permet d’exécuter le RPC à distance sur l’équipement. Dans la définition rpc, l’instruction junos:command définit la commande utilisée pour exécuter le RPC dans l’interface de ligne de commande, qui est show intf statusdans ce cas .

Les junos:action-execute instructions définissent junos:script le script d’action invoqué lors de l’exécution du RPC. Cet exemple utilise un script d’action Python nommé rpc-interface-status.py pour récupérer les informations requises par le RPC et retourner les éléments de sortie XML tels que définis dans l’instruction RPC output .

Note:

À partir de La version 17.3 de Junos OS, l’instruction action-execute est un sous-état de command. Dans les versions antérieures, les action-execute instructions sont command placées au même niveau et l’instruction command est facultative.

Le rpc comporte un paramètre d’entrée nommé match, qui détermine les interfaces à inclure dans la sortie. Lorsque vous exécutez le RPC, vous incluez une chaîne correspondant aux interfaces souhaitées, par exemple ge-0*. Une chaîne vide (« ») s’allume sur toutes les interfaces. Le script d’action définit la valeur match par défaut comme une chaîne vide. Si l’utilisateur omet cet argument, la sortie contient des informations pour toutes les interfaces.

Le RPC définit également les nœuds de sortie qui doivent être émis par le script d’action correspondant. Le nœud racine est l’élément<interface-status-info>, qui contient au moins un certain <status-info> nombre d’éléments qui l’enferment et <status> les <interface> nœuds pour une interface correspondant. L’instruction junos-odl:format interface-status-info-format définit la mise en forme de la sortie affichée dans l’interface de ligne de commande. Ce nœud n’est pas émis dans l’arborescence XML de sortie.

Cet exemple présente deux versions du script d’action Python. Les scripts présentent des moyens différents de récupérer la sortie de commande opérationnelle, mais les deux scripts émettent une sortie RPC identique. Le premier script d’action utilise le module Python subprocess pour exécuter la show interfaces match-value | display xml commande, puis convertit la sortie de chaîne en XML. Le deuxième script d’action utilise Junos PyEZ pour exécuter l’équivalent RPC de la show interfaces match-value commande. Les deux scripts utilisent le code identique pour analyser la sortie de commande et extraire le nom et l’état opérationnel de chaque interface physique. Les scripts construisent le code XML de la sortie RPC, puis impriment la sortie, qui renvoie les informations à l’équipement. L’arborescence XML doit correspondre exactement à la hiérarchie définie dans le RPC.

Note:

Les équipements Junos définissent des espaces de noms dépendant des versions pour un grand nombre d’éléments du résultat opérationnel, y compris l’élément <interface-information> . Afin de rendre la version indépendante du système d’exploitation Rpc Junos, le code utilise la local-name() fonction dans les expressions XPath de ces éléments. Vous pouvez choisir d’inclure le mappage d’espace de noms comme argument et xpath() de qualifier les éléments avec l’espace de noms approprié.

Le module contenant le RPC et le fichier de script d’action sont ajoutés à l’équipement dans le cadre d’un nouveau package YANG nommé intf-rpc.

YANG Module

YANG Module

Le module YANG rpc-interface-status.yang définit le RPC, la commande utilisée pour exécuter le RPC dans l’interface de ligne de commande et le nom du script d’action à invoquer lors de l’exécution du RPC. Le nom de base du fichier doit correspondre au nom du module.

Script d’action

Le script d’action correspondant est rpc-interface-status.py. Cet exemple présente deux scripts d’action qui utilisent différents moyens pour récupérer les données. Un script utilise le module Python subprocess et l’autre utilise la bibliothèque PyEZ Junos. Les deux scripts émettent la même sortie XML RPC.

Note:

À partir de Junos OS Version 21.2R1 et Junos OS Evolved Version 21.2R1, lorsque l’équipement transmet des arguments de ligne de commande à un script d’action Python, il préfixe un trait d’union unique (-) vers des noms d’arguments à caractère unique et deux traits d’union (--) vers des noms d’arguments multi-caractères.

Script d’action (utilisation subprocess)

Le script d’action suivant utilise le module Python subprocess pour exécuter la commande opérationnelle et récupérer les données. Cet exemple fournit deux versions du script, qui gèrent correctement les arguments de ligne de commande du script pour les différentes versions.

Junos OS version 21.1 et antérieure

Junos OS version 21.2R1 et versions ultérieures

Script d’action (à l’aide de Junos PyEZ)

Le script d’action suivant utilise Junos PyEZ pour exécuter la commande opérationnelle et récupérer les données. Cet exemple fournit deux versions du script, qui gèrent correctement les arguments de ligne de commande du script pour les différentes versions.

Junos OS version 21.1 et antérieure

Junos OS version 21.2R1 et versions ultérieures

Permettre l’exécution de scripts Python

Pour permettre à l’équipement d’exécuter des scripts Python non signés :

  1. Configurez l’instructionlanguage python, language python3 le cas échéant, pour la version de Junos OS.
    Note:

    À partir de Junos OS version 20.2R1 et de Junos OS Evolved Version 22.3R1, l’équipement utilise Python 3 pour exécuter des scripts d’action et de traduction YANG. Dans les versions antérieures, Junos OS utilise Uniquement Python 2.7 pour exécuter ces scripts, et Junos OS Evolved utilise Python 2.7 par défaut pour exécuter les scripts.

  2. Validez la configuration.

Chargement du RPC sur l’unité

Pour ajouter le RPC et le script d’action au schéma Junos :

  1. Téléchargez le module YANG et le script d’action sur l’équipement Junos.
  2. Assurez-vous que le script d’action Python répond aux exigences suivantes :
    • Le propriétaire du fichier est racine ou utilisateur dans la classe de connexion Junos OS super-user .

    • Seul le propriétaire du fichier dispose de l’autorisation d’écriture pour le fichier.

    • Le script inclut la ligne de directive interpréteur appropriée, telle qu’elle est décrite dans créer des scripts d’action pour les RPC YANG sur les équipements Junos.

  3. (Facultatif) Validez la syntaxe du module YANG et du script d’action.
  4. Ajoutez le module YANG et le script d’action à un nouveau package YANG.
    Note:

    À partir de Junos OS Version 17.3R1, lorsque vous chargez des modèles de données YANG personnalisés sur l’équipement, vous n’avez pas besoin de charger explicitement les modules d’extension Junos OS requis. Dans les versions antérieures, vous devez charger les modules d’extension Junos OS pour tous les packages utilisant ces modules.

  5. Lorsque le système vous invite à redémarrer l’interface CLI de Junos OS, appuyez Enter sur pour accepter la valeur par défaut de yes, ou saisissez yes et appuyez sur Enter.

Vérification du RPC

But

Vérifiez que le RPC fonctionne comme prévu.

Action

Depuis le mode opérationnel, exécutez le RPC dans l’interface de ligne de commande en émettant la commande définie par l’instruction junos:command dans la définition RPC et incluez l’argument d’entrée match . Dans cet exemple, l’argument de correspondance est utilisé pour correspondre à toutes les interfaces qui commencent par ge-0.

Vous pouvez également ajuster la condition de correspondance pour retourner différents ensembles d’interfaces. Par exemple :

Pour renvoyer la même sortie au format XML, ajoutez le | display xml filtre à la commande.

Note:

Pour correspondre à toutes les interfaces, omettre l’argument match ou définir la valeur de l’argument sur une chaîne vide (« »).

Sens

Lorsque vous exécutez le RPC, l’équipement appelle le script d’action. Le script d’action exécute la commande opérationnelle pour récupérer les informations de l’interface sur l’équipement, analyse la sortie pour les informations souhaitées et imprime la hiérarchie XML pour la sortie RPC telle que définie dans l’instruction RPC output . Lorsque vous exécutez le RPC dans l’interface de ligne de commande, l’équipement utilise la mise en forme CLI définie dans le RPC pour convertir la sortie XML en sortie CLI affichée. Pour renvoyer la sortie XML d’origine, ajoutez le | display xml filtre à la commande.

Note:

Lorsque le RPC est exécuté à distance à l’aide de la balise de requête RPC, le format par défaut de la sortie est XML.

Dépannage des erreurs d’exécution RPC

Problème

Description

Lorsque vous exécutez le RPC, l’équipement génère l’erreur suivante :

Cause

L’utilisateur qui a invoqué le RPC ne dispose pas des droits nécessaires pour exécuter le script d’action Python correspondant.

Solution

Les utilisateurs ne peuvent exécuter des scripts Python non signés sur les équipements Junos que lorsque les autorisations de fichier du script incluent l’autorisation de lecture pour la première classe dans laquelle l’utilisateur se trouve, dans l’ordre de l’utilisateur, du groupe ou d’autres.

Vérifiez si le script dispose des autorisations nécessaires pour l’exécution du script et ajustez les autorisations, le cas échéant. Si vous mettez à jour les autorisations, vous devez également mettre à jour le package YANG pour que cette modification prenne effet. Par exemple :

Tableau Historique des versions
Libération
Description
21.2R1 et 21.2R1-EVO
À partir de Junos OS Version 21.2R1 et Junos OS Evolved Version 21.2R1, lorsque l’équipement transmet des arguments de ligne de commande à un script d’action Python, il préfixe un trait d’union unique (-) vers des noms d’arguments à caractère unique et deux traits d’union (--) vers des noms d’arguments multi-caractères.