Utiliser Junos PyEZ pour valider la configuration

Lorsque vous utilisez l’utilitaire Junos PyEZ jnpr.junos.utils.config.Config pour apporter des modifications de configuration non structurées sur un équipement, vous validez la configuration du candidat en appelant la méthode d’instance Config commit() . Par exemple :

Pour vérifier la syntaxe de la configuration sans l’engager, appelez la méthode à la commit_check() place de la commit() méthode.

Lorsque vous utilisez les tables et vues de configuration Junos PyEZ pour apporter des modifications de configuration structurées sur un équipement, vous validez la configuration du candidat en appelant soit la set() méthode, qui appelle automatiquement le lock(), load()commit() et unlock() les méthodes, soit en appelant les différentes méthodes individuellement. Par exemple :

De même, vous pouvez appeler les méthodes individuelles, comme dans l’exemple suivant :

Note:

Si vous utilisez un gestionnaire de contexte pour créer l’objet Config ou Table et définir l’argument mode privatesur , exclusive, dynamic, batchou ephemeral, vous n’appelez que les load() méthodes et commit() pour configurer l’équipement. Le gestionnaire de contexte gère l’ouverture, le verrouillage, la fermeture et le déverrouillage de la base de données, de sorte que les appels vers le lock(), unlock()ou set() les méthodes de l’un de ces modes donnent une exception LockError.

La CLI Junos fournit des options pour l’opération de validation, telles que l’ajout d’un commentaire de validation ou la synchronisation de la configuration sur plusieurs moteurs de routage. Junos PyEZ prend en charge un grand nombre de ces mêmes options de validation et quelques options supplémentaires, que vous pouvez utiliser dans votre application Junos PyEZ en incluant les arguments appropriés dans la liste d’arguments ou set() de commit() méthode. Le tableau 1 présente les options de validation prises en charge et fournit la commande CLI correspondante.

Tableau 1 : Options de validation prises en charge par Junos PyEZ

Argument option de validation	Description	Commande CLI
comment="comment"	Consignez un commentaire pour cette opération de validation dans le fichier journal du système et dans l’historique de validation de l’équipement.	commit comment "comment"
confirm=(True | minutes)	Exigez qu’une opération de validation soit confirmée dans un délai spécifié après la validation initiale. Sinon, revenez à la configuration précédemment validée. Définissez l’argument pour True utiliser le temps par défaut de 10 minutes.	commit confirmed <minutes>
detail=True	Renvoyer un objet XML avec des informations détaillées sur le processus de validation.	commit | display detail | display xml
force_sync=True	Synchronisez et validez la configuration sur les deux moteurs de routage, même s’il y a des sessions de configuration ouvertes ou des modifications de configuration non validées sur l’autre moteur de routage.	commit synchronize force
ignore_warning=True ignore_warning="string" ignore_warning=["string1", "string2"]	Ignorez les avertissements déclenchés pendant l’opération de validation. Définissez l’argument pour True ignorer tous les avertissements, ou définissez l’argument sur une chaîne ou une liste de chaînes spécifiant les avertissements à ignorer.	–
sync=True	Synchronisez et validez la configuration sur les deux moteurs de routage.	commit synchronize
timeout=seconds	Attendez la fin de l’opération en utilisant la valeur spécifiée comme délai d’expiration.	–

Valider le commentaire

Lorsque vous validez la configuration, vous pouvez inclure un bref commentaire pour décrire l’objectif des modifications engagées. Pour consigner un commentaire décrivant les modifications, incluez le comment paramètre et une chaîne de message dans la commit() liste d’arguments ou set() de méthode, le cas échéant. Par exemple :

Inclure l’argument comment équivaut à envoyer la commande du commit comment mode de configuration dans la CLI. Le commentaire est enregistré dans le fichier journal système et inclus dans l’historique de validation de l’équipement, que vous pouvez consulter en publiant la show system commit commande dans la CLI.

Valider la confirmation

Pour exiger qu’une opération de validation soit confirmée dans un délai spécifié après la validation initiale, incluez l’argument dans la confirm=minutes liste d’arguments ou set() de commit() méthode, le cas échéant.

Si la validation n’est pas confirmée dans le délai imparti, l’équipement revient automatiquement à la configuration précédemment validée et envoie un message de diffusion à tous les utilisateurs connectés. La portée autorisée est de 1 à 65 535 minutes. Vous pouvez également spécifier confirm=True d’utiliser le temps de restauration par défaut de 10 minutes. Pour confirmer l’opération de validation, appelez la commit() méthode ou commit_check() .

L’opération de validation confirmée est utile pour vérifier qu’une modification de configuration fonctionne correctement et n’empêche pas la direction d’accéder à l’équipement. Si la modification empêche l’accès ou provoque d’autres erreurs, la restauration automatique vers la configuration précédente permet d’accéder à l’équipement après l’expiration de la date limite de restauration. Si vous perdez la connectivité à l’équipement, vous devez mettre en place la méthode Junos PyEZ open() pour restaurer la connectivité.

Détails de la validation

Vous pouvez consulter les détails de l’ensemble de l’opération de validation en incluant l’argument dans la detail=True liste ou set() des commit() arguments de méthode. Lorsque vous incluez cet argument, la méthode renvoie un objet XML avec des informations détaillées sur le processus de validation. La valeur de retour est équivalente au contenu joint par l’élément <commit-results> dans la sortie de la commit | display detail | display xml commande dans la CLI.

Synchronisation des validations

Si l’équipement dispose de deux moteurs de routage, vous pouvez synchroniser et valider la configuration sur les deux moteurs de routage en incluant l’argument dans la sync=True liste d’arguments ou set() de commit() méthode.

Lorsque vous incluez l’argument sync=True , l’équipement copie la configuration du candidat stockée sur le moteur de routage local vers l’autre moteur de routage, vérifie l’exactitude syntaxique du candidat et la valide sur les deux moteurs de routage. Pour forcer l’opération commit synchronize à réussir même s’il y a des sessions de configuration ouvertes ou des modifications de configuration non validées sur l’autre moteur de routage, utilisez l’argument force_sync=True , qui amène l’équipement à mettre fin à toutes les sessions de configuration sur l’autre moteur de routage avant de synchroniser et de confirmer la configuration.

Délai d’expiration des vérifications de validation et de validation

Le délai d’arrêt d’un RPC est par défaut de 30 secondes. Les modifications de configuration importantes peuvent dépasser cette valeur, ce qui entraîne un délai d’opération de validation ou de validation avant que la configuration ne puisse être téléchargée, vérifiée et validée. Pour prendre en charge les modifications de configuration pouvant nécessiter une vérification de validation ou un temps de validation plus long que l’intervalle de délai d’expiration par défaut, incluez l’argument timeout=seconds dans la commit_check()liste d’arguments de méthode ou set() dans commit() la liste d’arguments de méthode, et définissez l’intervalle d’expiration sur une valeur appropriée. Par exemple :

Ignorer les avertissements

Junos PyEZ soulève une RpcError exception lorsque la réponse RPC contient <rpc-error> des éléments avec une gravité d’avertissement ou supérieure. Dans les cas où il est nécessaire ou souhaitable de supprimer les RpcError exceptions qui sont soulevées en réponse à des avertissements, vous pouvez inclure le paramètre de ignore_warning la commit() méthode. Par exemple :

Pour plus d’informations sur l’utilisation du ignore_warning paramètre, voir Supprimer les exceptions RpcError soulevées pour les avertissements dans les applications Junos PyEZ.