Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Validation d’une configuration

La commande 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 commit configuration sur l’équipement.

Compréhension du modèle de validation des configurations

La configuration de l’équipement est enregistrée à l’aide d’un modèle de validation: une configuration du candidat est modifiée selon les souhaits, puis engagée sur le système. Lorsqu’une configuration est engagée, l’équipement vérifie la configuration en cas d’erreur de syntaxe et, si aucune erreur n’est trouvée, elle est enregistrée et juniper.conf.gz activée. Le fichier de configuration anciennement actif est enregistré sous la forme du premier fichier de configuration de retour en arrière (), et tous les autres fichiers de configuration de retour en arrière sont juniper.conf.1.gz incrémentés par 1. Par exemple, juniper.conf.1.gz est incrémenté vers, ce qui en fait le deuxième fichier de juniper.conf.2.gz configuration de retour en arrière. L’équipement peut économiser au maximum 49 configurations de retour en arrière (numérotés de 1 à 49) sur le système.

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

Si le fichier de configuration de récupération est enregistré sur le système, ce fichier doit également être rescue.conf.gz enregistré dans /config le répertoire. Les fichiers par défaut en usine sont situés dans /etc/config le répertoire.

Deux mécanismes sont utilisés pour propager les configurations entre les moteurs de routage au sein d’un équipement:

  • Synchronisation: Propage une configuration d’moteur de routage à une seconde moteur de routage dans le même châssis de l’équipement.

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

  • Distribution: Propage une configuration sur l’ensemble du plan de routage sur un équipement multichage. La distribution s’effectue automatiquement. Aucune commande utilisateur n’est disponible pour contrôler le processus de distribution. Si une configuration est verrouillée lors de la distribution d’une configuration, la configuration verrouillée ne reçoit pas le fichier de configuration distribué; la synchronisation échoue. Vous devez effacer la verrouille avant la configuration et resynchroniser les plans de routage.

    Remarque :

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

Validation d’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 commit mode de configuration. Vous pouvez émettre la commit commande à partir de n’importe quel niveau hiérarchique:

Lorsque vous saisissez la commande, la configuration est d’abord vérifiée en cas commit d’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 :

Il n’est pas recommandé d’effectuer une opération de validation sur la moteur de routage lorsque le basculement d’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 provoque l’échec de la vérification de validation.

  • La configuration de candidature que vous tentez de valider est supérieure à 700 Mo.

  • La configuration est verrouillée par un utilisateur qui a saisi 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:

Quelques chiffres clés :

Vous devez corriger l’erreur avant de récommitter la configuration. Pour revenir rapidement au niveau hiérarchique où l’erreur est située, copiez le chemin de la première ligne de l’erreur et collez-le au niveau de la configuration invite au niveau [edit] hiérarchique.

Le fichier de configuration du candidat non émis est /var/rundb/juniper.db . Il est limité à 700 Mo. Si la validation échoue à l’aide d’un message, affichez la taille du fichier à partir du configuration database size limit exceeded mode de configuration en entrant la run file list /var/rundb detail commande. 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 :

CLI messages de validation affichés pour les changements de configuration au niveau de la hiérarchie sont supprimés et enregistrés en tant que messages de [edit interfaces] 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 commitez une configuration, vous la commettez dans son formulaire actuel.

Remarque :
  • Il n’est pas recommandé d’effectuer une opération de validation sur la moteur de routage lorsque le basculement d’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 interface physique externe, par exemple, lorsque le basculement fxp0 GRES (Graceful moteur de routage Switchover) est activé, le CLI affiche un message d’erreur de validation approprié que des adresses identiques ont été trouvées sur les ge-0/0/1 interfaces privées et publiques. Dans ce cas, vous devez attribuer des adresses IP uniques pour les 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 de configuration simultanément, et ils peuvent tous apporter des modifications à la configuration. Toutes les modifications apportées par tous les utilisateurs sont visibles pour tout le monde qui modifie la configuration; ces modifications deviennent visibles dès que l’utilisateur appuie sur La clé Entrée à la fin d’une commande qui modifie la configuration, telle que setedit , ou delete .

Lorsque l’un des utilisateurs qui modifie une commande modifie une commande, toutes les modifications apportées par tous les utilisateurs sont contrôlées commit et activées.

Si vous entrez dans le mode de configuration avec la commande, chaque utilisateur dispose d’une configuration de candidat privée à modifier assez indépendamment configure private des autres utilisateurs. Lorsque vous commitez la configuration, seules vos propres modifications sont engagées. Pour synchroniser votre copie de la configuration après que d’autres utilisateurs ont déjà engagé des modifications, vous pouvez exécuter la commande update en mode de configuration. Une opération de validation met également à jour toutes les configurations de candidature privées. Par exemple, si l’utilisateur X et l’utilisateur Y sont tous deux en mode, alors que l’utilisateur X commit configure private une modification de configuration. Lorsque L’utilisateur Y effectue une opération de validation ultérieure, puis voit la nouvelle configuration, la nouvelle configuration vue par L’utilisateur Y inclut les modifications apportées par l’utilisateur X.

Si vous entrez le mode de configuration avec la commande, vous verrouillez la configuration du candidat aussi longtemps que vous restez en mode de configuration, ce qui vous permet d’apporter des modifications sans interférences de la part configure exclusive d’autres utilisateurs. D’autres utilisateurs peuvent entrer et quitter le mode de configuration, mais ils ne peuvent pas valider la configuration. Cela est vrai même si les autres utilisateurs ont entré le mode de configuration avant de saisir la configure exclusive commande. Par exemple, imaginons que l’utilisateur X soit déjà dans configure private le ou le configure mode. Imaginons que l’utilisateur Y pénètre dans le configure exclusive mode. L’utilisateur X ne peut pas valider de modifications à la configuration, même si ces modifications ont été saisies avant que l’utilisateur Y ne se connecte. Si l’utilisateur Y sort du mode, l’utilisateur X peut ensuite valider les configure exclusive modifications en mode ou en configure privateconfigure cours.

Présentation de la préparation et de l’activation des validations

À partir Junos OS version 17.3R1, vous pouvez terminer le processus de validation en deux étapes. Cette fonctionnalité vous permet de configurer plusieurs équipements et d’activer simultanément les configurations. Avant Junos OS mise à jour 17.3R1, le processus de validation a été effectué en une seule étape. Le but de la dissociation de ces étapes de validation est de fournir une période d’utilisation définitive pour que la validation soit efficace sur le système. Vous pouvez entrer le mode de validation après la préparation de la validation, mais vous recevrez un message informant que la validation est en attente d’activation.

Lors de la première étape, appelée 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é est affiché et la configuration n’est pas prête. En cas de défaillance au cours de la phase de préparation, le message d’erreur commit check-out failed s’affiche.

À la deuxième étape, appelée étape d’activation, la configuration préalablement préparée est activée. 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é une fois la validation en attente réussie.

Remarque :

Les opérations de validation ne peuvent pas être exécutées entre les phases de préparation et d’activation.

Le processus de validation en deux étapes est supérieur au processus en une étape pour les validations critiques dans le temps. Au cours d’un processus en une étape, le temps de préparation peut varier en fonction de la configuration existante sur l’équipement. Au cours du processus en deux étapes, les opérations de préparation complexes sont gérées 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 équipements avec les nouvelles configurations et les activer à l’heure exacte.

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

  • and-quit

  • no-synchronize

  • peers-synchronize

  • synchronize

Les commit prepare commandes et les commandes sont disponibles uniquement pour les commit activate validations privées, exclusives et partagées. Les commandes ne sont pas applicables pour les modes dynamiques et éphémères. Cette fonctionnalité s’applique aux équipements multichagessis, mais pas aux validations de batchs.

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 un MX Series Virtual Chassis, les exemples suivants s’appliquent: Lorsqu’elle est émise sur un moteur de routage suivi du basculement, l’moteur de routage où la commande de basculement commit prepare est émise redémarrage. Le cache préparé est donc autorisé dans cette moteur de routage.

  • Dans un tel MX Series Virtual Chassis, il est conseillé d’exécuter les commandes uniquement clear system commit prepared sur vc principal.

Validation des configurations d’équipements en deux étapes: Préparation et activation

À partir Junos OS version 17.3, vous pouvez terminer le processus de validation en deux étapes. Cela vous permet de configurer plusieurs équipements et les configurations peuvent être activées simultanément. Lors de la première étape, appelée 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é est affiché et la configuration n’est pas prête. Lors de la deuxième étape, appelée phase d’activation, la configuration préalablement préparée est activée et devient la configuration opérationnelle actuelle de l’équipement.

Pour préparer la configuration:

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

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

    Quelques chiffres clés :

  2. Émettre commit prepare la commande.

    Le message commit prepare successful s’affiche.

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

  3. Pour vérifier la sortie de la commande show system commit après l’émission, commit prepare 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é, utilisez la commande suivante:

Pour vérifier la sortie des commandes et après l’émission, show system commitshow system commit revision detailcommit activate émettre les commandes suivantes.

Activation d’une configuration de l’équipement, mais nécessitant une confirmation

Lorsque vous commitez la configuration du candidat actuel, vous pouvez demander une confirmation explicite pour que la validation devienne permanente. Cela vous sera utile si vous souhaitez vérifier qu’une modification de configuration fonctionne correctement et qu’elle n’empêche pas l’accès à l’équipement. Si la modification empêche l’accès ou provoque d’autres erreurs, le routeur revient automatiquement à la configuration précédente et rétablit l’accès après la confirmation de restauration. Cette fonctionnalité est appelée retour arrière automatique.

Pour valider la configuration du candidat actuel mais nécessitent une confirmation explicite de la validation pour devenir permanente, utilisez la commande 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 ou une commande dans commitcommit check les 10 minutes de la commit confirmed commande. Quelques chiffres clés :

Si la validation n’est pas confirmée à un certain moment (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’un retour en arrière est programmé après une commit confirmed commande, saisissez la show system commit commande. Quelques chiffres clés :

Tout comme la commit commande, la commande vérifie la syntaxe de configuration et commit confirmed signale les erreurs. En l’absence d’erreur, la configuration est activée temporairement (10 minutes par défaut) et commence à s’exécutant sur l’équipement.

Figure 1 : Confirmer une configurationConfirmer une configuration

Pour modifier le temps avant de confirmer la nouvelle configuration, spécifiez le nombre de minutes lors de l’émission de la commande:

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

Planification d’une opération de validation

Vous pouvez planifier quand vous souhaitez que la configuration de votre candidat soit active. Pour enregistrer les changements de configuration de l’équipement et activer la configuration sur le routeur à un moment ultérieure ou au redémarrage, utilisez la commande de mode de configuration, en spécifieant ou à une heure ultérieure au niveau de la hiérarchie commit atreboot [ ] edit :

À string quel moment ou à reboot l’avenir, vous pourz activer les changements de configuration. Vous pouvez spécifier l’heure dans deux formats:

  • Valeur horaire du formulaire [ [ heures, minutes et éventuellement secondes): validation de la configuration à l’heure indiquée, qui doit être ultérieurement mais avant 23 h hh:mm:ss 59 min 59 min le jour même de l’émission de la commande du mode de commit at configuration. Utilisez la durée de 24 heures pour en obtenir la valeur ; il est par exemple 4 h hh04:30:00 30 et 20 h 20:00 00. L’heure est interprétée par rapport aux paramètres d’horloge et de fuseau horaire du routeur.

  • Valeur de date et d’heure dans le formulaire yyyy-mm-dd hh:mm:ss ] (année, mois, date, heures, minutes et, éventuellement, secondes) — Commit the configuration at the specified day and time, which must be after the commit at command is issued. Utilisez la durée de 24 heures pour en obtenir hh la valeur. Le 2018-08-2112:30:00 21 août 2018, à 20 h 30, par exemple.  L’heure est interprétée par rapport aux paramètres d’horloge et de fuseau horaire du routeur.

Joint la string valeur dans les guillemets ( » « ). Par exemple, commit at "18:00:00" . Pour la date et l’heure, inclure les deux valeurs dans la même série de guillemets. Par exemple, commit at "2018-03-10 14:00:00".

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

Remarque :

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

Vous ne pouvez pas saisir la commit at commande de configuration après l’avoir request system reboot émise.

Vous ne pouvez pas saisir la commande une fois que vous avez programmé une opération request system reboot de validation à une heure spécifique à l’avenir.

Vous ne pouvez pas valider une configuration lorsqu’une validation programmée est en attente. Pour savoir comment annuler une configuration programmée à l’moyen de la commande, consultez clearCLI Explorer.

Remarque :

Il n’est pas recommandé d’effectuer une opération de validation sur l’moteur de routage lorsque le basculement d’moteur de routage est activé sur l’équipement.

Surveillance du processus de validation

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

Quelques chiffres clés :

Ajout d’un commentaire pour décrire la configuration engagée

Vous pouvez inclure un commentaire décrivent les modifications apportées à la configuration initiale. Pour ce faire, inclure commit comment l’énoncé. Le commentaire peut prendre la forme de 512 octets et vous devez le écrire sur une seule ligne.

comment-string est le texte du commentaire.

Remarque :

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

Pour ajouter un commentaire à la commit commande, inclure comment l’énoncé suivant la commit commande:

Pour ajouter un commentaire à la commit confirmed commande, inclure comment l’énoncé suivant la commit confirmed commande:

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

Remarque :

À partir Junos OS version 11.4, vous pouvez également utiliser la commande commit confirmed dans le mode de [edit private] configuration.

Présentation des validations par lot

Batch commit aggregates or merges multiple configuration edits from different CLI users and adds them to a batch commit queue. Un serveur de validation par batchs s’exécutant sur l’équipement prend une ou plusieurs tâches à partir de la file d’attente de validation par lot, applique les modifications de configuration à la base de données de configuration partagée, puis commit les modifications de configuration dans une seule opération de validation.

Les batchs 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 à l’ajout de la tâche de batch. Lorsqu’un lot de validation est terminé, l’ensemble suivant de modifications de configuration est agrégé et chargé dans la file d’attente de lot pour la prochaine session de l’opération de validation par lot. Des lots sont créés jusqu’à ce qu’il n’y a aucune entrée de validation dans le répertoire de la file d’attente.

Par rapport aux opérations de validation régulières où toutes les validations sont engagées de façon indépendante, les validations par lot gagnent du temps et les ressources système en commitant plusieurs petites modifications de configuration au cours d’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 [edit system commit server] de la hiérarchie.

Agrégation et gestion des erreurs

En cas d’erreur de temps de charge dans l’une des tâches agrégées, la tâche de validation qui rencontre l’erreur est écartée et les tâches restantes sont agrégées et engagées.

Par exemple, si cinq tâches de validation (, , et ) sont agrégées et rencontrent une erreur lors du chargement, sont éliminées et , et sont agrégées et commit-1commit-2commit-3commit-4commit-5commit-3commit-3commit-1commit-2commit-4commit-5 engagées.

En cas d’erreur au cours de l’opération de validation lorsque deux tâches ou plus sont agrégées et engagées, l’agrégation est écartée et chaque travail est réalisé individuellement comme une opération de validation régulière.

Par exemple, s’il y a cinq tâches de validation (, , et ) agrégées et qu’une erreur de validation est causée par , l’agrégation est écartée, , et engagée commit-1 individuellement, et le CLI signale une erreur de validation pour commit-2commit-3commit-4commit-5commit-3commit-1commit-2commit-3commit-4commit-5commit-3 .

Exemple: Configuration des propriétés du serveur de validation par lot

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

Conditions préalables

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

  • Plate-forme de routage universelle 5G MX Series

  • Junos OS version 12.1 ou ultérieure s’exécutant sur l’équipement

Présentation

Vous pouvez contrôler la manière dont la file d’attente de validation par lot est gérée par le serveur de validation en configurant les propriétés du serveur au niveau [edit system commit server] de la hiérarchie. Cela vous permet de contrôler le nombre de tâches de validation agrégées ou fusionnables dans un même commit, le nombre maximal de tâches qui peuvent être ajoutées à la file d’attente, les jours pour conserver les journaux d’erreur de validation par lots, l’intervalle entre deux validations de lots et les opérations de suivi pour les opérations de validation de batch.

Configuration

CLI configuration rapide

Pour configurer rapidement cette section de l’exemple, copiez les commandes suivantes, collez-les dans un fichier texte, supprimez les interruptions de ligne, modifiez tous les détails nécessaires pour correspondre à votre configuration réseau, puis copiez-les et collez dans le CLI au niveau de la [edit] hiérarchie. Vous pouvez configurer les propriétés du serveur de validation à partir du mode régulier [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 l’agrégation ou la fusion au cours d’une seule opération de validation.

    La valeur par défaut maximum-aggregate-pool est 5 .

    Remarque :

    La maximum-aggregate-pool définition de valider chacune des tâches 1 individuellement.

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

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

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

    Remarque :

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

  3. (Facultatif) Configurez l’heure (en secondes) pour attendre avant de commencer l’opération de validation de lot suivant.

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

    La valeur par défaut est de 30 plusieurs jours.

  5. (Facultatif) Configurer les opérations de traçage pour journaliser les événements de validation par lots.

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

Résultats

À partir du mode de 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 batch

Procédure étape par étape

Pour valider la configuration à partir du [edit batch] mode, faites l’une des utilisations suivantes:

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

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

  • Pour valider une configuration sans agrégation des changements de configuration avec d’autres tâches de validation dans la file d’attente, modifiez la commande commit avec atomic l’option.

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

Vérification

Vérifier que la configuration fonctionne correctement.

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

But

Vérifier l’état du serveur de validation par lot.

Action

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

Lorsqu’un travail de validation par lot est ajouté à la file d’attente, l’état du serveur de validation Running change.

Sens

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

Vérification du statut de validation des lots

But

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

Action
Sens

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

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

But

Affichez les timestamps, les fichiers de correctifs et l’état de chaque travail de validation. Les fichiers correctifs indiquent les modifications de configuration qui se produisent dans chaque opération de validation ajoutée à la file d’attente de validation par lot.

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 de configuration pour chaque ID de travail de validation.

  2. Pour afficher le correctif pour un ID de travail de validation spécifique, émettre 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. L’ou le panneau indique les modifications de + configuration pour une tâche de validation - spécifique.

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

But

Afficher les fichiers de suivi pour les opérations de validation par lots. Vous pouvez utiliser les fichiers de traçage à des fins de dépannage.

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

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

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

    La sortie affiche les ID de travail de validation par lot pour la réussite des opérations de validation.

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

    La sortie affiche les ID de travail de validation pour les opérations de validation inattente.

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

    Le résultat affiche les journaux d’événements du serveur de validation.

Backing Up the Committed Configuration on the Alternate Boot Drive

Une fois la configuration réussie et que vous êtes convaincu qu’elle fonctionne correctement, vous devez émettre la commande de back request system snapshot up the new software sur le système de /altconfig fichiers. Si la commande n’est pas émise, la configuration du lecteur de démarrage alternatif n’est plus en phase avec la request system snapshot configuration du lecteur de démarrage principal.

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

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