Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
SUR CETTE PAGE
 

Exemple : modification de la configuration à l’aide de scripts SLAX et XSLT Op

Cet exemple explique comment apporter des modifications structurées à la configuration de Junos OS à l’aide d’un script d’opération SLAX.

Configuration de l’appareil

Procédure étape par étape

Pour télécharger, activer et tester le script :

  1. Copiez le script dans un fichier texte, nommez le fichier config-change.slax et copiez-le dans le répertoire /var/db/scripts/op/ de l’appareil.

  2. En mode configuration, configurez le nom de fichier du script au niveau de la [edit system scripts op file] hiérarchie.

  3. Exécutez la commit and-quit commande pour valider la configuration et revenir en mode opérationnel.

  4. Avant d’exécuter le script, exécutez la show interfaces interface-name commande en mode opérationnel et enregistrez l’état actuel de l’interface qui sera désactivée par le script.

  5. Exécutez le script op.

Exigences

Cet exemple utilise un périphérique exécutant Junos OS.

Vue d’ensemble et script d’opération

Les scripts SLAX et XSLT peuvent utiliser le jcs:load-configuration modèle, qui se trouve dans le fichier d’importation junos.xsl , pour apporter des modifications structurées à la configuration de Junos OS. Cet exemple crée un script d’opération SLAX qui utilise le jcs:load-configuration modèle pour désactiver une interface sur un périphérique exécutant Junos OS. Toutes les valeurs requises pour le jcs:load-configuration modèle sont définies sous forme de variables, qui sont ensuite transmises au modèle.

Dans cet exemple, la usage variable est initialisée avec une description générale de la fonction du script. Lorsque vous exécutez le script, il appelle la jcs:output() fonction pour afficher la description d’utilisation dans l’interface de ligne de commande. Cela vous permet de vérifier que vous utilisez le script dans le bon but.

Le script appelle la jcs:get-input() fonction, qui demande le nom de l’interface à désactiver et stocke le nom de l’interface dans la interface variable. La config-changes variable stocke les données de configuration XML Junos à charger sur l’équipement et fait référence à la interface variable. L’appel jcs:load-configuration de modèle définit la configuration valeur du paramètre sur les données stockées dans la config-changes variable.

La load-action variable est définie sur merge, ce qui fusionne les nouvelles données de configuration avec la configuration candidate. Il s’agit de l’équivalent de la commande load mergeCLI configuration mode .

La options variable définit les options de l’opération de validation. Il utilise l’opérateur := pour créer un ensemble de nœuds, qui est transmis au modèle en tant que valeur du commit-options paramètre. Cet exemple inclut la log balise permettant d’ajouter la description de la validation au journal de validation pour référence ultérieure.

L’appel à la jcs:open() fonction ouvre une connexion avec le processus de gestion de Junos OS (mgd) sur le périphérique local et renvoie un descripteur de connexion stocké dans la conn variable. Le script appelle ensuite le jcs:load-configuration modèle.

L’opérateur := copie les résultats de l’appel jcs:load-configuration de modèle dans une variable temporaire et exécute la node-set fonction sur cette variable. L’ensemble de nœuds résultant est ensuite stocké dans la results variable. L’opérateur := s’assure que la results variable est un ensemble de nœuds plutôt qu’un fragment d’arborescence de résultats afin que le script puisse accéder au contenu.

La jcs:close() fonction ferme la connexion à l’appareil. Par défaut, le jcs:load-configuration modèle n’envoie pas de messages à l’interface de ligne de commande. Cet exemple recherche et imprime des xmn:warning xnm:error messages dans la réponse pour identifier rapidement les problèmes liés à la validation.

Syntaxe SLAX

Vérification

Vérification de la validation

But

Vérifiez que la validation a réussi.

Action

Vous devez inclure du code dans votre script qui analyse l’ensemble de nœuds renvoyé par le modèle à la recherche d’erreurs jcs:load-configuration ou d’avertissements. Cela vous permet de déterminer plus facilement si la validation a réussi. S’il n’y a pas d’avertissement ou de message d’erreur, vous pouvez vérifier la réussite de la validation de plusieurs manières.

  • Consultez le journal de validation pour vérifier que la validation a réussi. Si vous avez inclus l’option log dans le commit-options paramètre, le message doit être visible dans le journal de validation avec les informations de validation.

  • Vérifiez le fichier de messages syslog pour vérifier que l’opération de validation a été consignée. Dans ce cas, vous voyez également un SNMP_TRAP_LINK_DOWN message pour l’interface désactivée so-0/0/0. En fonction de vos paramètres de configuration pour les traceoptions, ce message peut apparaître ou non dans votre fichier journal.

Vérification des modifications de configuration

But

Vérifiez que les modifications correctes sont intégrées dans la configuration.

Action

  • Affichez la configuration et vérifiez que les modifications sont visibles pour l’interface spécifiée.

  • Pour cet exemple, vous pouvez également exécuter la show interfaces interface-name commande mode opérationnel pour vérifier que l’interface a été désactivée. Dans ce cas, la sortie capturée avant la désactivation de l’interface indique que l’interface est Enabled.

    La sortie capturée après l’exécution du script pour désactiver l’interface montre que l’interface est maintenant Administratively down.

Documentation connexe