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 mode de configuration vous permet d’enregistrer les modifications apportées à la configuration de l’appareil dans la base de données de configuration et d’activer la configuration sur l’appareil.

Le modèle de validation des configurations

La configuration de l’appareil est enregistrée à l’aide d’un modèle de validation : une configuration candidate est modifiée comme vous le souhaitez, puis validée dans le système. Lorsqu’une configuration est validée, l’appareil 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. L’ancien fichier de configuration 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 de 1. Par exemple, juniper.conf.1.gz il est incrémenté à juniper.conf.2.gz, ce qui en fait le deuxième fichier de configuration de restauration. Un maximum de 49 configurations de restauration (numérotées de 1 à 49) peuvent être enregistrées sur le système.

Sur l’appareil, 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, il 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 sont utilisés pour propager les configurations entre les moteurs de routage au sein d’un appareil :

  • Synchronisation: Propage une configuration d’un moteur de routage à 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 périphérique multichâssis. La distribution s’effectue automatiquement. Il n’y a pas de commande utilisateur 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 effacer le verrou avant la configuration et resynchroniser les plans de routage.

    REMARQUE :

    Lorsque vous utilisez la commande CLI sur une plate-forme multichâssis, la synchronisation forcée des fichiers de configuration n’affecte pas la commit synchronize force distribution du fichier de configuration sur le plan de routage. Si un fichier de configuration est verrouillé sur un périphérique distant de l’appareil sur lequel la commande a été émise, la synchronisation échoue sur le périphérique distant. Vous devez effacer le verrou et réexécuter la synchronization commande.

Voir également

Valider la configuration d’un appareil

Pour enregistrer les modifications apportées à la configuration de l’appareil dans la base de données de configuration et activer la configuration sur l’appareil, utilisez la commit commande mode de configuration. Vous pouvez exécuter la commit commande à partir de n’importe quel niveau hiérarchique :

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

REMARQUE :

Nous vous déconseillons d’effectuer une opération de validation sur le moteur de routage de sauvegarde lorsque le basculement normal 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 taille de la configuration candidate 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 valider à nouveau la configuration. Pour revenir rapidement au niveau hiérarchique où se trouve l’erreur, copiez le chemin d’accès 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 candidat non validé 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 à partir du 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 les filtres de votre pare-feu.

REMARQUE :

Les avertissements de validation de l’interface de ligne de commande affichés pour les modifications de configuration au niveau hiérarchique [edit interfaces] sont supprimés et consignés en tant que 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’intégralité de la configuration dans sa forme actuelle.

REMARQUE :

  • Nous vous déconseillons d’effectuer une opération de validation sur le moteur de routage de sauvegarde lorsque le basculement normal du moteur de routage est activé sur l’appareil.

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

Opération de validation lorsque plusieurs utilisateurs configurent le logiciel

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

Lorsqu’un utilisateur qui modifie la configuration émet une commit commande, l’interface de ligne de commande vérifie et active toutes les modifications apportées par tous les utilisateurs.

Si vous passez en mode configuration à l’aide de la commande, chaque utilisateur dispose d’une configure private configuration candidate privée à modifier indépendamment des autres utilisateurs. Lorsque vous validez la configuration, l’interface de ligne de commande valide uniquement vos propres modifications. Pour synchroniser votre copie de la configuration après que d’autres utilisateurs ont validé les modifications, vous pouvez exécuter la update commande en mode configuration. Une opération de validation met également à jour toutes les configurations candidates privées. Par exemple, supposons que l’utilisateur X et l’utilisateur Y soient tous 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 ensuite la nouvelle configuration, la nouvelle configuration vue par l’utilisateur Y inclut les modifications apportées par l’utilisateur X.

Si vous passez en mode configuration à l’aide de la commande, vous verrouillez la configure exclusive configuration candidate tant que vous restez en mode configuration. Cela vous permet d’apporter des modifications sans interférence des autres utilisateurs. Les 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 que vous n’entriez la configure exclusive commande. Par exemple, supposons que l’utilisateur configure private X soit déjà en mode ou configure . Supposons ensuite que l’utilisateur Y entre dans le configure exclusive mode. L’utilisateur X ne peut pas valider les modifications apportées à la configuration, même si l’utilisateur X a saisi ces modifications avant que l’utilisateur Y ne se connecte. Si l’utilisateur Y quitte le configure exclusive mode, l’utilisateur X peut alors valider les modifications effectuées dans configure private le mode or configure .

Vue d’ensemble de la préparation et de l’activation des validations

Vous pouvez terminer le processus de validation en deux étapes. La fonction de validation en deux étapes vous permet de configurer plusieurs appareils et d’activer simultanément les configurations. La validation en deux étapes fournit une fenêtre de temps définitive pour que la validation soit effective sur le système. Vous pouvez passer 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 un premier temps, la phase de préparation, le commit est validé 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 un deuxième temps, l’étape d’activation, la configuration préalablement préparée est activée. Ensuite, si vous avez besoin d’effacer la configuration préparée, vous pouvez le faire à l’aide clear system commit prepared de la commande. Un message de journal est généré lors de l’effacement réussi 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 urgentes. Dans le processus en une seule étape, le temps de préparation peut varier en fonction de la configuration existante sur l’appareil. Dans le processus en deux étapes, le travail de préparation complexe est géré plus efficacement.

Des commandes de configuration sont fournies pour vous permettre de préparer le cache de configuration et d’activer la configuration. Vous pouvez préparer les appareils avec de nouvelles configurations et les activer aux moments exacts que vous souhaitez.

La commit prepare commande valide les configurations, et la commit activate commande active les configurations. Les commandes ont les options de configuration suivantes :

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

Les commit prepare commandes et ne sont disponibles que pour les validations privées, exclusives et commit activate partagées. Les commandes ne sont pas applicables pour les modes dynamiques et éphémères. Cette fonctionnalité s’applique aux équipements multichâssis, mais pas aux validations par lots.

Pour prendre en charge cette fonctionnalité à l’aide du protocole de configuration réseau (NETCONF), 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 MX Series Virtual Chassis, les règles suivantes s’appliquent : Lorsqu’elle commit prepare est émise sur un moteur de routage suivi d’un basculement, le moteur de routage dans lequel la commande de basculement est émise redémarre. Par conséquent, le cache préparé est effacé dans ce moteur de routage.

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

Validez les configurations des appareils en deux étapes : Préparation et activation

Vous pouvez terminer le processus de validation en deux étapes. Cela vous permet de configurer plusieurs appareils, et les configurations peuvent être activées simultanément. Dans un premier temps, appelé phase de préparation, le commit est validé 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. Dans la deuxième étape, appelée étape d’activation, la configuration précédemment préparée est activée et devient la configuration actuelle de l’appareil opérationnel.

Pour préparer la configuration :

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

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

    Par exemple :

  2. Exécutez la commit prepare commande.

    Le message commit prepare successful s’affiche.

    En cas d’échec de l’étape de préparation, le message commit check-out failed d’erreur s’affiche.

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

Pour activer la configuration préparée :

  1. Utilisez 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 la sortie des show system commit commandes and show system commit revision detail after commit activate est émise, exécutez les commandes suivantes.

Activation d’une configuration d’appareil avec confirmation

Lorsque vous validez la configuration candidate actuelle, vous pouvez exiger une confirmation explicite pour que la validation devienne permanente. Ceci est utile si vous souhaitez vérifier qu’une modification de configuration fonctionne correctement et n’empêche pas l’accès à l’appareil. Si la modification empêche l’accès ou provoque d’autres erreurs, l’équipement revient automatiquement à la configuration précédente et rétablit l’accès une fois le délai de confirmation de restauration écoulé. C’est ce qu’on appelle la restauration automatique.

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

Une fois que vous avez vérifié que la modification fonctionne correctement, vous pouvez garder la nouvelle configuration active en entrant une commit commande ou commit check 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 quand une restauration est planifiée après une commit confirmed commande, entrez la show system commit commande. Par exemple :

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

Figure 1 : Confirmer une configurationConfirmer une configuration

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

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

Planifier une opération de validation

Vous pouvez planifier le moment où vous souhaitez que votre configuration de candidat devienne active. Pour enregistrer les modifications apportées à la configuration de l’appareil et activer la configuration sur l’appareil à une date ultérieure ou au redémarrage, utilisez la commande de mode de commit at configuration, en spécifiant reboot une heure ultérieure au niveau de la hiérarchie [edit] :

string est reboot ou l’heure future pour activer les modifications 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 dans le futur, mais avant 23 h 59 min 59 s le jour où la commit at commande de mode de configuration est émise. Utilisez l’heure de 24 heures pour la hh valeur ; par exemple, 04:30:00 est 4 :30 :00 AM et 20:00 est 20 :00 PM. L’heure est interprétée par rapport aux paramètres de l’horloge et du fuseau horaire sur le routeur.

  • Valeur de date et d’heure sous la 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 postérieurs à l’exécution de la commit at commande. Utilisez l’heure de 24 heures pour la hh valeur. Par exemple, 2018-08-21 12:30:00  est 12 :30 PM le 21 août 2018. L’heure est interprétée par rapport aux paramètres de l’horloge et du fuseau horaire sur le routeur.

Mettez 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 exécutez la commande configuration commit at mode. Si le résultat de la vérification réussit, 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’appareil échoue avant que les modifications de configuration ne deviennent actives, toutes les modifications de configuration sont perdues.

Vous ne pouvez pas entrer la commande de commit at configuration après avoir exécuté la request system reboot commande.

Vous ne pouvez pas entrer la request system reboot commande une fois que vous avez planifié une opération de validation pour une heure spécifique dans le futur.

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, reportez-vous à l’Explorateurclear CLI.

REMARQUE :

Nous vous déconseillons d’effectuer une opération de validation sur le moteur de routage de sauvegarde lorsque le basculement normal du moteur de routage est activé sur l’appareil.

Surveiller le processus de validation

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

Par exemple :

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

Vous pouvez inclure un commentaire décrivant les modifications apportées à la configuration validée. Pour ce faire, incluez l’instruction commit comment . Le commentaire peut faire jusqu’à 512 octets et vous devez le taper sur une seule ligne.

comment-string est le texte du commentaire.

REMARQUE :

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

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

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

Pour afficher ces commentaires de validation, exécutez la commande du show system commit mode opérationnel.

REMARQUE :

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

Vue d’ensemble des validations par lots

La validation par lots agrège ou fusionne plusieurs modifications de configuration provenant de différentes sessions CLI ou utilisateurs et les ajoute à une file d’attente de validation par lots. Un serveur de validation par lots s’exécutant sur l’appareil prend une ou plusieurs tâches de 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 en 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ée par l’utilisateur ou de l’heure à laquelle le traitement par lots est ajouté. Lorsqu’une validation par lots est terminée, l’ensemble suivant de modifications de configuration est agrégé et chargé dans la file d’attente de traitement par lots pour la session suivante de l’opération de validation par lots. Les lots sont créés jusqu’à ce qu’il n’y ait plus d’entrées de validation dans le répertoire de la file d’attente.

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

Les validations par lots sont effectuées à partir du [edit batch] mode de 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 existe une erreur de chargement dans l’une des tâches agrégées, la tâche de validation qui rencontre l’erreur est ignorée et les tâches restantes sont agrégées et validées.

Par exemple, s’il y a cinq tâches de validation (commit-1, commit-2, commit-3, commit-4et commit-5) en cours d’agrégation et commit-3qu’une erreur est rencontrée lors du chargement, commit-3elles sont ignorées et commit-1, commit-2,commit-4, et commit-5 sont agrégées et validées.

S’il y a une erreur pendant l’opération de validation lorsque deux ou plusieurs tâches sont agrégées et validées, l’agrégation est ignoré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 (commit-1, commit-2, commit-3, commit-4et commit-5) sont agrégées et qu’une erreur de validation est causée par commit-3, l’agrégation est ignorée, commit-1,commit-2, commit-3, commit-4 et commit-5 sont validées individuellement, et que l’interface de ligne de commande signale une erreur de validation pour commit-3.

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 façon dont la file d’attente de validation par lots est gérée 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 lots, le nombre maximal de tâches pouvant être ajoutées à la file d’attente, les jours de conservation des 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 de l’interface de ligne de commande

Pour configurer rapidement cette section de l’exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les sauts de ligne, modifiez les détails nécessaires pour qu’ils correspondent à votre configuration réseau, puis copiez et collez les commandes dans l’interface de ligne de commande 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.

Appareil R0

Configuration des propriétés du serveur de validation

Procédure étape par étape

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

    La valeur par défaut de maximum-aggregate-poolest 5.

    REMARQUE :

    Paramètre maximum-aggregate-pool sur 1 valide 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 qui sont ajoutées à la file d’attente.

    REMARQUE :

    Si vous définissez maximum-entries sur 1, le serveur de validation ne peut pas ajouter plus d’une tâche à la file d’attente, et l’interface de ligne de commande affiche un message approprié lorsque vous essayez de valider plusieurs tâches.

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

  4. (Facultatif) Configurez le nombre de jours de conservation des journaux d’erreurs.

    La valeur par défaut est 30 days.

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

    Dans cet exemple, le nom de fichier pour la journalisation des événements de validation par lots est commitd_nov, et tous les indicateurs 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’appareil et saisissez commit.

  • Pour attribuer une priorité plus élevée à un travail de validation par lots, exécutez 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, exécutez 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 en attribuant une priorité plus élevée à la tâche de validation, exécutez la commit commande avec l’option atomic priority .

Vérification

Vérifiez que la configuration fonctionne correctement.

Vérification de l’état du serveur de validation par lots

But

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

Action

Par défaut, l’état du serveur de validation est Not running. Le serveur de validation ne commence à s’exécuter que lorsqu’une tâche de validation par lots est ajoutée à la file d’attente.

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

Sens

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

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

But

Vérifiez la file d’attente du serveur de validation pour connaître l’état des validations par lots.

Action
Sens

Pending commits Affiche les tâches de validation qui sont ajoutées à la file d’attente de validation, mais qui ne le sont pas encore. Completed commits Affiche la liste des tâches de validation qui ont réussi. Error commits sont des validations qui ont échoué à cause d’une erreur.

Affichage des fichiers de correctifs dans une tâche de validation par lots

But

Affichez 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 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 de toutes les opérations de validation.

    La sortie affiche les modifications apportées à la configuration pour chaque ID de tâche de validation.

  2. Pour afficher le correctif d’un ID de tâche de validation spécifique, exécutez la show system commit server queue patch id <id-number> commande.

Sens

La sortie montre le correctif créé pour une tâche de validation. Le + signe ou - indique les modifications apportées à la configuration d’une tâche de validation spécifique.

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

But

Affichez 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.

    La sortie 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, exécutez la file show /var/log/<filename> commande avec l’option | match committed pipe.

    La sortie affiche les ID de tâche de validation par lots pour les opérations de validation réussies.

  • Pour afficher les entrées de journal uniquement pour les opérations de validation par lots ayant échoué, exécutez la file show /var/log/<filename> commande avec l’option | match “Error while” de canal.

    La sortie affiche les ID de tâche de validation pour les opérations de validation ayant échoué.

  • Pour afficher les entrées de journal uniquement pour les événements du serveur de validation, exécutez 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.

Sauvegardez la configuration validée sur l’autre disque d’amorçage

Une fois que vous avez validé la configuration et que vous êtes convaincu qu’elle s’exécute correctement, vous devez exécuter la request system snapshot commande de sauvegarde du nouveau logiciel sur le système de /altconfig fichiers. Si vous n’exécutez pas la commande, la configuration sur le lecteur de démarrage secondaire n’est pas synchronisée avec la request system snapshot configuration sur le lecteur de démarrage principal.

La request system snapshot commande sauvegarde le système de fichiers racine dans /altroot, et /config dans /altconfig. Les systèmes racine et de /config fichiers se trouvent sur la clé USB du routeur, tandis que les systèmes de /altroot fichiers et /altconfig se trouvent sur le disque dur du routeur (si disponible).

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

Rubriques connexes