Présentation de la génération de modifications de configuration persistantes ou transitoires à l’aide de scripts de validation
Les scripts de validation Junos OS appliquent des règles de configuration personnalisées. Lorsqu’une configuration de candidat inclut des déclarations que vous avez décidé de ne pas inclure dans votre configuration, ou lorsque la configuration du candidat omet les déclarations que vous avez décidées sont requises, les scripts de validation peuvent automatiquement modifier la configuration et ainsi corriger le problème.
Différences entre les changements persistants et transitoires
Les modifications de configuration apportées par les scripts de validation peuvent être persistantes ou transitoires.
Une modification persistante reste dans la configuration du candidat et affecte les opérations de routage jusqu’à ce que vous la supprimiez explicitement, même si vous supprimez ou désactivez par la suite le script de validation qui a généré la modification et rééditez la commit commande. En d’autres termes, la suppression du script de validation n’entraîne pas la suppression d’une modification persistante de la configuration.
En revanche, une modification transitoire est effectuée dans la configuration de paiement , mais pas dans la configuration du candidat. La configuration de caisse est la base de données de configuration qui est inspectée pour la syntaxe Junos OS standard juste avant qu’elle ne soit copiée pour devenir la configuration active sur l’équipement. Si vous supprimez ou désactivez par la suite le script de validation qui a effectué la modification et rééditez la commit commande, la modification n’est plus apportée à la configuration de paiement et n’affecte donc pas la configuration active. En d’autres termes, la suppression du script de validation supprime effectivement une modification transitoire de la configuration.
Les modifications transitoires sont couramment utilisées pour éliminer le besoin de configurer et d’afficher à plusieurs reprises des stratégies bien connues, ce qui permet d’appliquer implicitement ces stratégies. Par exemple, si MPLS doit être activé sur chaque interface avec un protocole ISO (Organisation internationale de normalisation), la modification peut être transitoire, de sorte que les données de configuration répétitives ou redondantes ne doivent pas être portées ou affichées dans la configuration candidate. En outre, les modifications transitoires vous permettent d’écrire des instructions de script qui appliquent la modification uniquement si un ensemble de conditions est rempli.
Les modifications persistantes et transitoires sont chargées dans la configuration de la même manière que la commande du load replace mode de configuration charge une configuration entrante. Lors de la génération d’une modification persistante ou transitoire, l’ajout de l’attribut replace="replace" à un élément de configuration produit le même comportement qu’une replace: balise dans une load replace opération.
Par défaut, Junos OS fusionne la configuration entrante et la configuration du candidat. De nouvelles déclarations et hiérarchies sont ajoutées, et les déclarations contradictoires sont remplacées. Lorsque vous génèrent une modification persistante ou transitoire, si vous ajoutez l’attribut replace="replace" à un élément de configuration, Junos OS remplace l’élément de configuration existant par l’élément de configuration entrant. Si l’attribut replace="replace" est ajouté à un élément de configuration, mais qu’aucun élément du même nom n’existe dans la configuration actuelle, l’élément de configuration entrant est ajouté à la configuration. Les éléments qui n’ont pas l’attribut replace sont fusionnés dans la configuration.
Les modifications persistantes et transitoires sont chargées avant que les vérifications de validation standard de Junos OS ne soient effectuées. Cela signifie que toute modification de configuration introduite par un script de validation est validée pour la syntaxe correcte. Si la syntaxe est correcte, la nouvelle configuration devient la configuration active et opérationnelle de l’équipement.
Les éléments protégés de la hiérarchie de configuration ne peuvent pas être modifiés ou supprimés par une modification persistante ou transitoire. Si un script de validation tente de modifier ou de supprimer une déclaration ou une hiérarchie protégée, Junos OS émet un avertissement indiquant que la modification ne peut pas être effectuée et procède à la validation.
Les changements persistants et transitoires présentent plusieurs différences importantes, comme le décrit le tableau 1.
Changements persistants |
Changements transitoires |
|---|---|
Vous pouvez représenter une modification persistante dans les scripts de validation en utilisant le Les scripts de validation SLAX et XSLT peuvent également représenter une modification persistante à l’aide de la |
Vous pouvez représenter une modification transitoire des scripts de validation avec le Les scripts de validation SLAX et XSLT peuvent également représenter un changement transitoire à l’aide de la |
Vous pouvez utiliser des modifications persistantes pour effectuer n’importe quelle opération du protocole Junos XML, par exemple activer, désactiver, supprimer, insérer (réordonner), commenter (annoter) et remplacer les sections de la configuration. |
Comme les modifications persistantes, vous pouvez utiliser des modifications transitoires pour effectuer n’importe quelle opération de protocole Junos XML. Cependant, certaines opérations du protocole Junos XML n’ont pas de sens à utiliser avec des modifications transitoires, telles que la génération de commentaires et de paramètres inactifs. |
Les modifications persistantes sont toujours chargées pendant le processus de validation si aucune erreur n’est générée par des scripts de validation ou par le contrôle de validité standard de Junos OS. |
Pour que les modifications transitoires soient chargées, vous devez inclure l’instruction Comme les modifications persistantes, les modifications transitoires doivent passer la vérification de validité standard de Junos OS. |
Les modifications persistantes fonctionnent comme la Lors de la génération d’une modification persistante, si vous ajoutez l’attribut |
Les modifications transitoires fonctionnent comme la Lorsque vous génèrent une modification transitoire, si vous ajoutez l’attribut Les modifications transitoires ne sont pas copiées dans la configuration du candidat. Pour cette raison, les modifications transitoires ne sont pas enregistrées dans la configuration si le script de validation associé est supprimé ou désactivé. |
Une fois qu’une modification persistante est validée, le logiciel la traite comme une modification que vous apportez en modifiant et en engageant directement la configuration du candidat. Une fois les modifications persistantes copiées dans la configuration du candidat, elles sont copiées dans la configuration de paiement. Si les modifications passent les vérifications de validité standard de Junos OS, les modifications sont propagées aux composants du commutateur, du routeur ou de l’équipement de sécurité. |
Chaque fois qu’une modification transitoire est validée, le logiciel met à jour la base de données de configuration de caisse. Une fois que les modifications transitoires ont passé les vérifications de validité standard de Junos OS, les modifications sont propagées aux composants de l’équipement. |
Après avoir validé un script qui génère une modification persistante, vous pouvez afficher la modification persistante en envoyant la commande du user@host# show Cette commande affiche uniquement les modifications persistantes, et non les modifications transitoires. |
Après avoir validé un script à l’origine d’une modification transitoire, vous pouvez afficher la modification transitoire en publiant la commande du user@host# show | display commit-scripts Cette commande affiche les modifications persistantes et transitoires. |
Les modifications persistantes doivent être conformes aux règles de conception de configuration personnalisées dictées par les scripts de validation. Cela ne devient apparent qu’après une deuxième opération de validation, car les modifications persistantes ne sont pas évaluées par les règles de script de validation sur l’opération de validation en cours. L’opération de validation suivante échoue si les modifications persistantes ne sont pas conformes aux règles imposées par les scripts de validation configurés lors de la première opération de validation. |
Les modifications transitoires ne sont jamais testées par et n’ont pas besoin de se conformer à vos règles personnalisées. Cela est dû à l’ordre des opérations du modèle de validation Junos OS, qui est expliqué en détail dans les scripts de validation et le modèle de validation Junos OS. |
Une modification persistante reste dans la configuration même si vous supprimez, désactivez ou désactivez les instructions du script de validation qui ont généré la modification. |
Si vous supprimez, désactivez ou désactivez les instructions de script de validation qui génèrent une modification transitoire, la modification est supprimée de la configuration après la prochaine opération de validation. En bref, si les instructions associées ou l’intégralité du script de validation sont supprimés, la modification transitoire est également supprimée. |
Comme pour la configuration cli directe, vous pouvez supprimer une modification persistante en revenir à une configuration précédente qui n’incluait pas la modification et en publiant la |
Vous ne pouvez pas supprimer une modification transitoire en revenir à une configuration précédente. |
Vous pouvez modifier directement les modifications persistantes en modifiant la configuration à l’aide de la CLI. |
Vous ne pouvez pas modifier ou supprimer directement une modification transitoire à l’aide de l’interface cli de Junos OS, car la modification n’est pas dans la configuration du candidat. Pour modifier le contenu d’une modification transitoire, vous devez modifier les instructions du script de validation qui génère la modification transitoire. |
Interaction des modifications de configuration et des groupes de configuration
Toute modification de configuration que vous pouvez effectuer en modifiant directement la configuration à l’aide de l’interface de ligne de commande (CLI) Junos OS peut également être générée par un script de validation en tant que modification persistante ou transitoire. Cela inclut les valeurs spécifiées à un niveau hiérarchique spécifique ou dans des groupes de configuration. Comme pour la configuration CLI directe, les valeurs spécifiées dans la cible remplacent les valeurs héritées d’un groupe de configuration. La cible est l’instruction à laquelle vous appliquez un groupe de configuration en incluant l’instruction apply-groups .
Si vous définissez des modifications persistantes ou transitoires comme appartenant à un groupe de configuration, les groupes de configuration sont appliqués dans l’ordre que vous spécifiez dans les apply-groups instructions, que vous pouvez inclure à n’importe quel niveau hiérarchique, à l’exception du niveau supérieur. Vous pouvez également désactiver l’héritage d’un groupe de configuration en incluant l’instruction apply-groups-except à n’importe quel niveau hiérarchique, à l’exception du niveau supérieur.
Chaque script de validation inspecte la vue post-héritique de la configuration. Si une configuration de candidat contient un groupe de configuration, faites attention lorsque vous utilisez un script de validation pour modifier la configuration cible associée, car cela risque de modifier l’héritage prévu du groupe de configuration.
Faites également attention lorsque vous utilisez un script de validation pour modifier un groupe de configuration, car le groupe de configuration peut être généré par une application qui effectue une load replace opération sur le groupe au cours de chaque opération de validation.
Pour plus d’informations sur les groupes de configuration, consultez le Guide de l’utilisateur CLI .
Balises d’éléments et modèles pour générer des modifications
Pour générer des modifications persistantes ou transitoires dans les scripts de validation, les scripts SLAX et XSLT peuvent utiliser le jcs:emit-change modèle, et les scripts Python peuvent utiliser la jcs.emit_change méthode. Le jcs:emit-change modèle et la jcs.emit_change méthode incluent implicitement des <change> éléments ET <transient-change> XML. Les scripts SLAX et XSLT peuvent également générer des modifications en incluant les <change> éléments et <transient-change> directement dans le script de validation. L’utilisation du jcs:emit-change modèle dans les scripts SLAX et XSLT vous permet de définir le contexte hiérarchique de la modification une fois plutôt que plusieurs fois. Dans les scripts Python, la jcs.emit_change méthode exige que les données de configuration pour la modification demandée incluent le chemin de configuration complet représentant tous les niveaux de la hiérarchie de configuration formatés en tant que chaîne XML.
Les <change> éléments et <transient-change> sont similaires à l’opération <load-configuration> définie par le protocole de gestion Junos XML. Le contenu possible des <change> éléments et <transient-change> des éléments est identique au contenu de l’élément <configuration> de balise utilisé dans l’opération <load-configuration>de protocole Junos XML . Pour plus d’informations sur l’élément <load-configuration> , consultez le Guide du développeur Junos XML Management Protocol .