Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Sur cette page
 

Valider la configuration

La commit commande du mode de configuration vous permet d’enregistrer les modifications de configuration de l’équipement dans la base de données de configuration et d’activer la configuration sur l’équipement.

Modèle de validation pour les configurations

La configuration de l’équipement est enregistrée à l’aide d’un modèle de validation: une configuration de candidat est modifiée comme souhaité, puis validée sur le système. Lorsqu’une configuration est validée, l’équipement vérifie la configuration à la recherche d’erreurs de syntaxe, et si aucune erreur n’est détectée, la configuration est enregistrée et juniper.conf.gz activée. Le fichier de configuration précédemment actif est enregistré en tant que premier fichier de configuration de restauration (juniper.conf.1.gz), et tous les autres fichiers de configuration de restauration sont incrémentés par 1. Par exemple, juniper.conf.1.gz est incrémenté vers juniper.conf.2.gz, ce qui en fait le deuxième fichier de configuration de restauration. L’équipement peut enregistrer un maximum de 49 configurations de restauration (numérotées de 1 à 49) sur le système.

Sur l’équipement, le fichier de configuration actuel et les trois premiers fichiers de restauration (juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3) se trouvent dans le /config répertoire. (Les fichiers de restauration restants, de 4 à 49, se trouvent dans /var/db/config.)

Si le fichier rescue.conf.gz de configuration de récupération existe, ce fichier se trouve également dans le /config répertoire. Les fichiers d’usine par défaut se trouvent dans le /etc/config répertoire.

Deux mécanismes permettent de propager les configurations entre les moteurs de routage au sein d’un équipement :

  • Synchronisation: Propage une configuration d’un moteur de routage vers un deuxième moteur de routage dans le même châssis d’équipement.

    Pour synchroniser les configurations, utilisez la commit synchronize commande CLI. Si l’un des moteurs de routage est verrouillé, la synchronisation échoue. Si la synchronisation échoue en raison d’un fichier de configuration verrouillé, vous pouvez utiliser la commit synchronize force commande. Cette commande remplace le verrou et synchronise les fichiers de configuration.

  • Distribution: Propage une configuration sur le plan de routage sur un équipement multichassis. La distribution se fait automatiquement. Aucune commande utilisateur n’est disponible pour contrôler le processus de distribution. Si une configuration est verrouillée lors d’une distribution d’une configuration, la configuration verrouillée ne reçoit pas le fichier de configuration distribué, de sorte que la synchronisation échoue. Vous devez vider le verrou avant la configuration et resynchroniser les plans de routage.

    REMARQUE :

    Lorsque vous utilisez la commit synchronize force commande CLI sur une plate-forme multichassis, la synchronisation forcée des fichiers de configuration n’affecte pas la distribution du fichier de configuration sur le plan de routage. Si un fichier de configuration est verrouillé sur un équipement distant de l’équipement où la commande a été émise, la synchronisation échoue sur l’équipement distant. Vous devez vider le verrou et rééditer la synchronization commande.

Voir également

Valider une configuration d’équipement

Pour enregistrer les modifications de configuration de l’équipement dans la base de données de configuration et pour activer la configuration sur l’équipement, utilisez la commande du commit mode de configuration. Vous pouvez émettre la commande depuis n’importe commit quel niveau hiérarchique :

Lorsque vous saisissez la commit commande, la configuration est d’abord vérifiée pour détecter des erreurs de syntaxe (commit check). Ensuite, si la syntaxe est correcte, la configuration est activée et devient la configuration actuelle de l’équipement opérationnel.

REMARQUE :

Nous ne recommandons pas d’effectuer une opération de validation sur le moteur de routage de secours lorsque le basculement du moteur de routage est activé sur le routeur.

Une validation de configuration peut échouer pour l’une des raisons suivantes :

  • La configuration inclut une syntaxe incorrecte, ce qui entraîne l’échec de la vérification de validation.

  • La configuration du candidat que vous essayez de valider est supérieure à 700 Mo.

  • La configuration est verrouillée par un utilisateur qui a entré la configure exclusive commande.

Si la configuration contient des erreurs de syntaxe, un message indique l’emplacement de l’erreur et la configuration n’est pas activée. Le message d’erreur a le format suivant :

Par exemple :

Vous devez corriger l’erreur avant de renouveler la configuration. Pour revenir rapidement au niveau hiérarchique où se trouve l’erreur, copiez le chemin de la première ligne de l’erreur et collez-le à l’invite du mode de configuration au niveau de la [edit] hiérarchie.

Le fichier de configuration du candidat non engagé est /var/rundb/juniper.db. Il est limité à 700 Mo. Si la validation échoue avec un message configuration database size limit exceeded, affichez la taille du fichier depuis le mode de configuration en entrant la commande run file list /var/rundb detail. Vous pouvez simplifier la configuration et réduire la taille du fichier en créant des groupes de configuration avec des caractères génériques ou en définissant des stratégies de correspondance moins spécifiques dans vos filtres de pare-feu.

REMARQUE :

Les avertissements cli en temps de validation affichés pour les modifications de configuration au niveau de la [edit interfaces] hiérarchie sont supprimés et sont consignés sous forme de messages de journal système.

Cela s’applique également à la configuration VRRP aux niveaux hiérarchiques suivants :

  • [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

  • [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

Lorsque vous validez une configuration, vous validez l’ensemble de la configuration dans sa forme actuelle.

REMARQUE :

  • Nous ne recommandons pas d’effectuer une opération de validation sur le moteur de routage de secours lorsque le basculement du moteur de routage est activé sur l’équipement.

  • Si vous configurez la même adresse IP pour une interface de gestion ou une interface interne telle qu’une fxp0 interface physique externe telle que ge-0/0/1, lorsque le basculement GRES (Graceful Routing Engine Switchover) est activé, la CLI affiche un message d’erreur de validation approprié indiquant que des adresses identiques ont été trouvées sur les interfaces privées et publiques. Dans de tels cas, vous devez attribuer des adresses IP uniques aux deux interfaces qui ont des adresses dupliquées.

Opération de validation lorsque plusieurs utilisateurs configurent le logiciel

Jusqu’à 32 utilisateurs peuvent être en mode configuration en apportant simultanément des modifications à la configuration. Toutes les modifications apportées par tous les utilisateurs sont visibles par tous les utilisateurs qui modifient la configuration : elles deviennent visibles dès que l’utilisateur appuie sur la touche Entrée à la fin d’une commande qui modifie la configuration, telle que set, editou delete.

Lorsque l’un des utilisateurs qui modifient la configuration lance une commit commande, la CLI vérifie et active toutes les modifications par tous les utilisateurs.

Si vous entrez en mode configuration avec la configure private commande, chaque utilisateur dispose d’une configuration de candidature privée à modifier indépendamment des autres utilisateurs. Lorsque vous validez la configuration, l’interface CLI valide uniquement vos propres modifications. Pour synchroniser votre copie de la configuration après que d’autres utilisateurs ont engagé des modifications, vous pouvez exécuter la update commande en mode configuration. Une opération de validation met également à jour toutes les configurations de candidats privés. Par exemple, supposons que l’utilisateur X et l’utilisateur Y sont tous les deux en configure private mode, et que l’utilisateur X valide une modification de configuration. Lorsque l’utilisateur Y effectue une opération de validation ultérieure et affiche la nouvelle configuration, la nouvelle configuration vue par l’utilisateur Y inclut les modifications apportées par l’utilisateur X.

Si vous entrez en mode configuration avec la configure exclusive commande, vous verrouillez la configuration du candidat aussi longtemps que vous restez en mode de configuration. Cela vous permet d’effectuer des modifications sans interférence des autres utilisateurs. D’autres utilisateurs peuvent entrer et sortir du mode de configuration, mais ils ne peuvent pas valider la configuration. Cela est vrai même si les autres utilisateurs sont entrés en mode de configuration avant d’entrer la configure exclusive commande. Par exemple, supposons que l’utilisateur X est déjà en configure private mode ou configure . Supposez que l’utilisateur Y entre dans le configure exclusive mode. L’utilisateur X ne peut valider aucune modification de la configuration, même si l’utilisateur X a entré ces modifications avant que l’utilisateur Y ne se connecte. Si l’utilisateur Y sort configure exclusive du mode, l’utilisateur X peut alors valider les modifications apportées en mode ou configure en configure private mode.

Présentation de la préparation et de l’activation de la validation

Vous pouvez terminer le processus de validation en deux étapes. La fonctionnalité de validation en deux étapes vous permet de configurer plusieurs équipements et d’activer simultanément les configurations. La validation en deux étapes offre une période de temps définitive pour que la validation soit efficace sur le système. Vous pouvez entrer en mode de validation une fois la validation préparée, mais vous recevrez un message indiquant que la validation est en attente d’activation.

Dans la première étape, la phase de préparation, la validation est validée et une nouvelle base de données avec les fichiers nécessaires est générée. Si la configuration contient des erreurs de syntaxe, un message d’erreur approprié s’affiche et la configuration n’est pas préparée. En cas de défaillance pendant la phase de préparation, le message commit check-out failedd’erreur s’affiche.

Dans la deuxième étape, l’étape d’activation, la configuration préparée précédemment est activée. Ensuite, si vous devez effacer la configuration préparée, vous pouvez le faire à l’aide de clear system commit prepared la commande. Un message de journal est généré lors de l’annulation réussie de la validation en attente.

REMARQUE :

Vous ne pouvez pas effectuer d’opérations de validation entre les étapes de préparation et d’activation.

Le processus de validation en deux étapes est supérieur au processus en une seule étape pour les validations critiques. Dans le processus en une seule étape, le temps de préparation peut varier en fonction de la configuration existante sur l’équipement. Dans le processus en deux étapes, le travail de préparation complexe est géré plus efficacement.

Des commandes de configuration vous permettent de préparer le cache de configuration et d’activer la configuration. Vous pouvez préparer les équipements avec de nouvelles configurations et les activer au moment exact de votre choix.

La commit prepare commande valide les configurations et active commit activate les configurations. Les commandes disposent des options de configuration suivantes :

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

Les commit prepare commandes et commit activate sont disponibles uniquement pour les validations privées, exclusives et partagées. Les commandes ne s’appliquent pas aux modes dynamiques et éphémères. Cette fonctionnalité s’applique aux équipements multichassis, mais elle ne l’est pas pour les validations par lots.

Pour prendre en charge cette fonctionnalité à l’aide du protocole NETCONF (Network Configuration Protocol), les nouveaux appels de procédure à distance (RPC) suivants sont fournis :

  • <commit-configuration>< prepare/></commit-configuration>

  • <commit-configuration><activate/></commit-configuration>

  • <clear-system-commit><prepared/></clear-system-commit>

REMARQUE :

  • Dans une configuration Virtual Chassis MX Series, les éléments suivants s’appliquent : Lorsqu’il commit prepare est émis sur un moteur de routage suivi d’un basculement, le moteur de routage sur lequel la commande de commutation est émise redémarre. Par conséquent, le cache préparé est vide dans ce moteur de routage.

  • Dans une configuration Virtual Chassis MX Series, il est conseillé d’exécuter clear system commit prepared la commande uniquement sur VC principal.

Valider les configurations des équipements en deux étapes : Préparation et activation

Vous pouvez terminer le processus de validation en deux étapes. Vous pouvez ainsi configurer plusieurs équipements et activer simultanément les configurations. Dans la première étape, connue sous le nom de phase de préparation, la validation est validée et une nouvelle base de données ainsi que les fichiers nécessaires sont générés. Si la configuration contient des erreurs de syntaxe, un message d’erreur approprié s’affiche et la configuration n’est pas préparée. Dans la deuxième étape, appelée phase d’activation, la configuration préparée précédemment est activée et devient la configuration actuelle de l’équipement opérationnel.

Pour préparer la configuration :

  1. Au niveau hiérarchique [edit] en mode de configuration, apportez les modifications nécessaires à la configuration.

    Par exemple, pour configurer les scripts du système, la commande suivante :

    Par exemple :

  2. Émettez la commit prepare commande.

    Le message commit prepare successful s’affiche.

    Si la phase de préparation échoue, le message commit check-out failed d’erreur s’affiche.

  3. Pour vérifier la sortie de la commande après commit prepare son show system commit émission, utilisez la commande suivante :

Pour activer la configuration préparée :

  1. Utiliser la commit activate commande

    Le message commit complete s’affiche.

  2. Pour vérifier la configuration du système activée, utilisez la commande suivante :

Pour vérifier le résultat et les show system commitshow system commit revision detail commandes après commit activate avoir été émises, émettez les commandes suivantes.

Activer une configuration d’équipement avec confirmation

Lorsque vous validez la configuration actuelle du candidat, vous pouvez exiger une confirmation explicite pour que la validation devienne permanente. Cela est utile si vous souhaitez vérifier qu’une modification de configuration fonctionne correctement et n’empêche pas l’accès à l’équipement. Si la modification empêche l’accès ou provoque d’autres erreurs, l’équipement revient automatiquement à la configuration précédente et restaure l’accès une fois le délai de confirmation de restauration passé. Cette fonctionnalité est appelée restauration automatique.

Pour valider la configuration de candidature actuelle, mais exiger une confirmation explicite pour que la validation devienne permanente, utilisez la commande du commit confirmed mode de configuration :

Une fois que vous avez vérifié que la modification fonctionne correctement, vous pouvez maintenir la nouvelle configuration active en entrant une commit ou commit check commande dans les 10 minutes suivant la commit confirmed commande. Par exemple :

Si la validation n’est pas confirmée dans un certain délai (10 minutes par défaut), le système d’exploitation revient automatiquement à la configuration précédente et un message de diffusion est envoyé à tous les utilisateurs connectés.

Pour afficher lorsqu’une restauration est planifiée après une commit confirmed commande, saisissez la show system commit commande. Par exemple :

Comme la commit commande, elle vérifie la commit confirmed syntaxe de configuration et signale toute erreur. S’il n’y a pas d’erreur, la configuration est activée temporairement (10 minutes par défaut) et commence à s’exécuter sur l’équipement.

Figure 1 : Confirmer une configuration Confirmer une configuration

Pour modifier le délai avant de confirmer la nouvelle configuration, spécifiez le nombre de minutes lorsque vous émettez la commande :

Vous pouvez également utiliser la commit confirmed commande dans le mode de [edit private] configuration.

Planifier une opération de validation

Vous pouvez planifier quand vous souhaitez que la configuration de votre candidat soit active. Pour enregistrer les modifications de configuration de l’équipement et activer la configuration sur l’équipement à un moment ultérieur ou lors d’un redémarrage, utilisez la commit at commande du mode de configuration, en spécifiant reboot ou une heure ultérieure au niveau de la hiérarchie [edit] :

string est reboot ou le moment futur d’activer les changements de configuration. Vous pouvez spécifier l’heure dans deux formats :

  • Valeur de temps sous la forme hh:mm[:ss] (heures, minutes et éventuellement secondes) : validez la configuration à l’heure spécifiée, qui doit être à l’avenir, mais avant 23:59:59 le jour où la commit at commande du mode de configuration est émise. Utilisez un temps de 24 heures pour la hh valeur , par exemple, 04:30:00 est 04:30:00 et 20:00 est 20:00 pm. L’heure est interprétée en fonction de l’horloge et des paramètres du fuseau horaire sur le routeur.

  • Date et heure sous forme yyyy-mm-dd hh:mm[:ss] (année, mois, date, heures, minutes et, éventuellement, secondes) : validez la configuration au jour et à l’heure spécifiés, qui doivent être après l’émission de la commit at commande. Utilisez un temps de 24 heures pour la hh valeur. Par exemple, 2018-08-21 12:30:00 il est 12 h 30 le 21 août 2018. L’heure est interprétée en fonction de l’horloge et des paramètres du fuseau horaire sur le routeur.

Joignez la string valeur entre guillemets (« »). Par exemple, commit at "18:00:00". Pour la date et l’heure, incluez les deux valeurs dans le même ensemble de guillemets. Par exemple, commit at "2018-03-10 14:00:00".

Une vérification de validation est effectuée immédiatement lorsque vous émettez la commande du mode de commit at configuration. Si le résultat de la vérification est réussi, l’utilisateur actuel est déconnecté du mode de configuration et les données de configuration sont laissées en lecture seule. Aucune autre validation ne peut être effectuée tant que la validation planifiée n’est pas terminée.

REMARQUE :

Si le logiciel de l’équipement échoue avant que les modifications de configuration ne deviennent actives, toutes les modifications de configuration sont perdues.

Vous ne pouvez pas saisir la commande de commit at configuration une fois la commande passée request system reboot .

Vous ne pouvez pas saisir la request system reboot commande une fois que vous planifiez une opération de validation pour une période spécifique à l’avenir.

Vous ne pouvez pas valider une configuration lorsqu’une validation planifiée est en attente. Pour plus d’informations sur l’annulation d’une configuration planifiée à l’aide de la commande, consultez l’Explorateur clearCLI.

REMARQUE :

Nous ne recommandons pas d’effectuer une opération de validation sur le moteur de routage de secours lorsque le basculement du moteur de routage est activé sur l’équipement.

Surveiller le processus de validation

Pour surveiller le processus de validation de la configuration de l’équipement, utilisez la display detail commande après le tuyau avec la commit commande :

Par exemple :

Ajouter un commentaire pour décrire la configuration engagée

Vous pouvez inclure un commentaire décrivant les modifications apportées à la configuration validée. Pour ce faire, incluez l’énoncé commit comment . Le commentaire peut être aussi long que 512 octets et vous devez le saisir sur une seule ligne.

comment-string est le texte du commentaire.

REMARQUE :

Vous ne pouvez pas inclure un commentaire avec la commit check commande.

Pour ajouter un commentaire à la commit commande, ajoutez l’instruction comment après la commit commande :

Pour ajouter un commentaire à la commit confirmed commande, ajoutez l’instruction comment après la commit confirmed commande :

Pour consulter ces commentaires de validation, émettez la commande du show system commit mode opérationnel.

REMARQUE :

Vous pouvez également utiliser la commit confirmed commande dans le mode de [edit private] configuration.

Présentation des validations par lot

La validation par lots agrège ou fusionne plusieurs modifications de configuration à partir de différentes sessions ou utilisateurs CLI et les ajoute à une file d’attente de validation par lots. Un serveur de validation par lots s’exécutant sur l’équipement prend une ou plusieurs tâches dans la file d’attente de validation par lots, applique les modifications de configuration à la base de données de configuration partagée, puis valide les modifications de configuration dans une seule opération de validation.

Les lots sont hiérarchisés par le serveur de validation en fonction de la priorité du lot spécifié par l’utilisateur ou de l’heure d’ajout du travail par lot. Lorsqu’une validation par lot est terminée, les modifications de configuration suivantes sont agrégées et chargées dans la file d’attente de lots pour la session suivante de l’opération de validation par lots. Les lots sont créés jusqu’à ce qu’il ne reste aucune entrée de validation dans le répertoire de file d’attente.

Par rapport à l’opération de validation normale où toutes les validations sont validées de manière séquentielle et indépendante, les validations par lots permettent de gagner du temps et des ressources système en commettant plusieurs petites modifications de configuration dans une seule opération de validation.

Les validations par lots sont effectuées à partir du mode de [edit batch] configuration. Les propriétés du serveur de validation peuvent être configurées au niveau de la [edit system commit server] hiérarchie.

Agrégation et gestion des erreurs

Lorsqu’il y a une erreur de temps de charge dans l’une des tâches agrégées, la tâche de validation qui rencontre l’erreur est ignorée et les autres tâches sont agrégées et validées.

Par exemple, si cinq tâches de validation (, , , et ) sont agrégées et commit-5commit-3 rencontrent une erreur pendant le chargement, commit-3 elles sont rejetées et commit-1, commit-2, commit-4et commit-5 sont agrégées et validées. commit-4commit-3commit-2commit-1

En cas d’erreur au cours de l’opération de validation lorsque deux tâches ou plus sont agrégées et validées, l’agrégation est rejetée et chacune de ces tâches est validée individuellement comme une opération de validation normale.

Par exemple, si cinq tâches de validation (, , , et ) sont agrégées et commit-5s’il y a une erreur de commit-3validation due à , l’agrégation est rejetée, commit-1, commit-2, commit-3, commit-4et commit-5 sont validées individuellement, et la CLI signale une erreur de validation pour commit-3. commit-4commit-3commit-2commit-1

Exemple : Configurer les propriétés du serveur de validation par lots

Cet exemple montre comment configurer les propriétés du serveur de validation par lots pour gérer les opérations de validation par lots.

Conditions préalables

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

  • Plate-forme de routage universelle 5G MX Series

Présentation

Vous pouvez contrôler la gestion de la file d’attente de validation par lots par le serveur de validation en configurant les propriétés du serveur au niveau de la [edit system commit server] hiérarchie. Cela vous permet de contrôler le nombre de tâches de validation agrégées ou fusionnées en une seule validation par lot, le nombre maximal de tâches pouvant être ajoutées à la file d’attente, les jours pour conserver les journaux d’erreurs de validation par lots, l’intervalle entre deux validations par lots et les opérations de suivi pour les opérations de validation par lots.

Configuration

Configuration rapide cli

Pour configurer rapidement cette section de l’exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, puis copiez et collez les commandes dans la CLI au niveau de la [edit] hiérarchie. Vous pouvez configurer les propriétés du serveur de validation à partir du mode normal [edit] ou du [edit batch] mode.

Équipement R0

Configuration des propriétés du serveur de validation

Procédure étape par étape

  1. (Facultatif) Configurez le nombre de transactions de validation pour agréger ou fusionner en une seule opération de validation.

    La valeur par défaut est maximum-aggregate-pool5.

    REMARQUE :

    1 Le paramétrage maximum-aggregate-pool pour valider chacune des tâches individuellement.

    Dans cet exemple, le nombre de transactions de validation est défini pour 4 indiquer que quatre tâches de validation différentes sont agrégées en une seule validation avant que l’opération de validation ne soit lancée.

  2. (Facultatif) Configurez le nombre maximal de tâches autorisées dans un lot.

    Cela limite le nombre de tâches de validation ajoutées à la file d’attente.

    REMARQUE :

    Si vous définissez la valeur maximum-entries1, le serveur de validation ne peut pas ajouter plusieurs tâches à la file d’attente, et l’interface CLI affiche un message approprié lorsque vous essayez de valider plusieurs tâches.

  3. (Facultatif) Configurez le temps d’attente (en quelques secondes) avant de commencer la prochaine opération de validation par lots.

  4. (Facultatif) Configurez le nombre de jours pour conserver les journaux d’erreurs.

    La valeur par défaut est 30 jours.

  5. (Facultatif) Configurez les opérations de suivi pour enregistrer les événements de validation par lots.

    Dans cet exemple, le nom de fichier pour la journalisation des événements de validation par lot est commitd_nov, et tous les indicateurs de traceoption sont définis.

Résultats

À partir du mode configuration, confirmez votre configuration en entrant la show system commit server commande. Si la sortie n’affiche pas la configuration prévue, répétez les instructions de cet exemple pour corriger la configuration.

Validation de la configuration à partir du mode de configuration par lots

Procédure étape par étape

Pour valider la configuration à partir du [edit batch] mode, effectuez l’une des opérations suivantes :

  • Connectez-vous à l’équipement et saisissez commit.

  • Pour accorder une priorité plus élevée à une tâche de validation par lots, émettez la commit commande avec l’option priority .

  • Pour valider une configuration sans agréger les modifications de configuration avec d’autres tâches de validation dans la file d’attente, émettez la commit commande avec l’option atomic .

  • Pour valider une configuration sans agréger les modifications de configuration avec d’autres tâches de validation dans la file d’attente, et sans accorder une priorité plus élevée à la tâche de validation, la commande commit avec l’option atomic priority .

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de l’état du serveur Batch Commit

But

Vérifiez l’état du serveur de validation par lots.

Action

Par défaut, le statut du serveur de validation est Not running. Le serveur de validation commence à s’exécuter uniquement lorsqu’une tâche de validation par lot est ajoutée à la file d’attente.

Lorsqu’une tâche de validation par lot est ajoutée à la file d’attente, le statut du serveur de validation passe à Running.

Sens

Le Jobs in process champ répertorie les ID de validation des tâches en cours.

Vérification de l’état de la validation des lots

But

Vérifiez l’état des validations par lot dans la file d’attente du serveur de validation.

Action
Sens

Pending commits affiche les tâches de validation qui sont ajoutées à la file d’attente de validation mais qui ne sont pas encore validées. Completed commits affiche la liste des tâches de validation réussies. Error commits sont des commits qui ont échoué en raison d’une erreur.

Consultation des fichiers de correctifs dans un travail de validation par lot

But

Consultez les horodatages, les fichiers de correctifs et l’état de chacune des tâches de validation. Les fichiers de correctifs affichent les modifications de configuration qui se produisent dans chaque opération de validation qui est ajoutée à la file d’attente de validation par lots.

Action

  1. Utilisez la show system commit server queue patch commande pour afficher les correctifs pour toutes les opérations de validation.

    Le résultat affiche les changements de configuration pour chaque ID de tâche de validation.

  2. Pour afficher le correctif d’un id de travail de validation spécifique, émettez la show system commit server queue patch id <id-number> commande.

Sens

Le résultat affiche le correctif créé pour une tâche de validation. Le + signe ou - indique les modifications apportées à la configuration d’un travail de validation spécifique.

Consultation des fichiers de trace pour les opérations de validation par lots

But

Consultez les fichiers de trace pour les opérations de validation par lots. Vous pouvez utiliser les fichiers de trace à des fins de dépannage.

Action

  • Utilisez la file show /var/log/<filename> commande pour afficher toutes les entrées du fichier journal.

    Le résultat affiche les journaux d’événements du serveur de validation et d’autres journaux pour les validations par lots.

  • Pour afficher les entrées de journal uniquement pour les opérations de validation par lots réussies, émettez la file show /var/log/<filename> commande avec l’option | match committed de pipe.

    Le résultat affiche les iDs de tâches de validation par lots pour des opérations de validation réussies.

  • Pour afficher les entrées de journal uniquement en cas d’échec des opérations de validation par lots, émettez la file show /var/log/<filename> commande avec l’option | match “Error while” pipe.

    Le résultat affiche les iDs de travail de validation pour les opérations de validation ayant échoué.

  • Pour afficher les entrées de journal uniquement pour les événements serveur de validation, émettez la file show /var/log/<filename> commande avec l’option | match “commit server” pipe.

    La sortie affiche les journaux d’événements du serveur de validation.

Sauvegarde de la configuration validée sur le lecteur de démarrage de remplacement

Une fois que vous avez valider la configuration et que vous êtes convaincu qu’elle fonctionne correctement, vous devez envoyer la request system snapshot commande de sauvegarde du nouveau logiciel sur le /altconfig système de fichiers. Si vous n’émettez pas la request system snapshot commande, la configuration sur le lecteur de démarrage de remplacement n’est pas synchronisée avec la configuration du lecteur de démarrage principal.

La request system snapshot commande sauvegarde le système de fichiers racine vers /altroot, et /config vers /altconfig. Les systèmes racines et /config de fichiers sont sur le lecteur flash du routeur, et les /altroot systèmes de fichiers /altconfig sont sur le disque dur du routeur (si disponible).

Après avoir exécuté la request system snapshot commande, vous ne pouvez pas revenir à la version précédente du logiciel, car les copies en cours d’exécution et de sauvegarde du logiciel sont identiques.

Rubriques connexes