Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Explication ligne par ligne des exemples de scripts de validation

Appliquer une modification aux interfaces SONET/SDH

Le script de validation XSLT suivant applique une modification transitoire à chaque interface dont le nom commence par so-, encapsulation sur ppp. Pour plus d’informations sur les modifications transitoires, consultez la présentation de La génération de modifications de configuration persistantes ou transitoires à l’aide de scripts de validation. Pour une version SLAX de cet exemple, reportez-vous à l’exemple : Générer un changement transitoire.

Les lignes 1 à 8 sont des chaudronneries telles que décrites dans le code « Required Boilerplate for Commit Scripts » et sont omises ici pour garantir la brièveté.

La ligne 9 est une <xsl:for-each> instruction de programmation qui examine chaque nœud d'interface dont le nom commence par « so- » et qui a été family inet activé sur n'importe quelle unité logique. (Il apparaît ici sur deux lignes seulement pour la concision.)

La ligne 10 est la balise ouverte pour une modification transitoire. Le contenu possible de l’élément <transient-change> est le même que le contenu de l’élément <configuration> de balise dans le fonctionnement <load-configuration>du protocole XML Junos .

Les lignes 11 à 16 représentent le contenu du changement transitoire. L’encapsulation est définie sur ppp.

Les lignes 17 à 19 ferment toutes les balises ouvertes de ce modèle.

La ligne 20 ferme la feuille de style et le script de validation.

Appliquer une modification aux interfaces compatibles ISO

L’exemple de script XSLT suivant garantit que les interfaces activées pour un protocole ISO (International Organization for Standardisation) sont également activées mpls et incluses au [edit protocols mpls interface] niveau hiérarchique. Pour une version SLAX de cet exemple, consultez l’exemple : Contrôler les interfaces IS-IS et MPLS.

Les lignes 1 à 8 sont des chaudronneries telles que décrites dans le code « Required Boilerplate for Commit Scripts » et sont omises ici pour garantir la brièveté.

La ligne 9 enregistre une référence au [edit protocols mpls] niveau hiérarchique de sorte qu’elle peut être référencée dans la boucle suivante for-each .

La ligne 10 examine chaque unité d’interface (interface logique) sur laquelle l’ISO est activée. Les select arrêts au niveau de unit, mais le prédicat limite la sélection aux seules unités qui contiennent un <iso> élément imbriqué sous un <family> élément.

La ligne 11 développe le nom de l’interface dans une variable. Premièrement, l’attribut name de la déclaration variable est défini sur ifname. Dans Junos OS, un nom d’interface correspond à la concaténation du nom de l’équipement, d’une période et du numéro d’unité. À ce stade du script, le nœud contextuel est le numéro d’unité, car la ligne 10 modifie le contexte en interfaces/interface/unité. Il ../name désigne l’élément <name> du nœud parent du nœud contextuel, qui est le nom de l’équipement (type-fpc/pic/port). Le jeton «name » de l’expression XPath fait référence à l’élément <name> du nœud contextuel, qui est le numéro d’unité (unit-number). Une fois la concaténation effectuée, l’expression XPath de la ligne 11 résout type-fpc/pic/port.unit-number. Comme l’instruction de la <xsl:for-each> ligne 10 traverse la hiérarchie et localise les interfaces compatibles ISO, les noms d’interface sont stockés de manière récursive dans la ifname variable.

La ligne 12 évalue que chaque interface compatible ISO n’est pas compatible MPLS.

La ligne 13 appelle le jcs:emit-change modèle, qui est un aide ou un modèle pratique dans le fichier junos.xsl. Ce modèle est traité dans les modèles émetteur-changement (SLAX et XSLT) et emit_change (Python).

Les lignes 14 à 18 utilisent les message paramètres du jcs:emit-change modèle. Le paramètre du message est un raccourci que vous pouvez utiliser au lieu d’inclure explicitement le <warning>, <edit-path>et <statement> les éléments.

Les lignes 19 à 23 utilisent les content paramètres du jcs:emit-change modèle. Le content paramètre spécifie la modification à apporter, par rapport au nœud de contexte actuel.

Les lignes 24 et 25 ferment respectivement les balises ouvertes sur les lignes 13 et 12.

La ligne 26 vérifie si MPLS est déjà activé et si cette interface n’est pas configurée au niveau de la [edit protocols mpls interface] hiérarchie.

Les lignes 27 à 41 contiennent une autre invocation du jcs:emit-change modèle. Dans cette invocation, l’interface est ajoutée au niveau de la [edit protocols mpls interface] hiérarchie.

Les lignes 42 à 45 ferment tous les éléments ouverts.