SUR CETTE PAGE
Opération de validation lorsque plusieurs utilisateurs configurent le Logiciels
Présentation de la préparation et de l’activation des validations
Validez les configurations des appareils en deux étapes : Préparation et activation
Ajouter un commentaire pour décrire la configuration validée
Exemple : Configurer les propriétés du serveur de validation par lots
Sauvegardez la configuration validée sur l’autre lecteur de démarrage
Validation de la configuration
La commit commande du mode de configuration vous permet d’enregistrer les modifications de 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 pour les configurations
La configuration de l’équipement 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 pour détecter les erreurs de syntaxe, et si aucune erreur n’est trouvée, la configuration est enregistrée en tant que juniper.conf.gz et 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 de 1. Par exemple, juniper.conf.1.gz est incrémenté à juniper.conf.2.gz, ce qui en fait le deuxième fichier de configuration de restauration. L’équipement peut avoir un maximum de 49 configurations de restauration (numérotées de 1 à 49) 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 répertoire /config . (Les fichiers de restauration restants, 4 à 49, se trouvent dans /var/db/config.)
Si le fichier de configuration de récupération existe rescue.conf.gz , ce fichier se trouve également dans le répertoire /config . Les fichiers d’usine par défaut se trouvent dans le répertoire /etc/config .
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 à un deuxième moteur de routage au sein du même châssis d’équipement.
Pour synchroniser les configurations, utilisez la
commit synchronizecommande 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 lacommit synchronize forcecommande. Cette commande remplace le verrou et synchronise les fichiers de configuration.-
Distribution : propage une configuration sur le plan de routage d’un équipement multichâssis. La distribution se fait automatiquement. Il n’y a pas de commande utilisateur 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é, de sorte que la synchronisation échoue. Vous devez libérer le verrou avant la configuration et resynchroniser les plans de routage.
Remarque :Lorsque vous utilisez la
commit synchronize forcecommande CLI sur une plate-forme multichâssis, 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 périphérique distant à partir du périphérique sur lequel la commande a été émise, la synchronisation échoue sur le périphérique distant. Vous devez effacer le verrou et réémettre lasynchronizationcommande.Remarque :Junos OS Evolved ne prend pas en charge les options de configuration suivantes
commit:-
fast-synchronize -
peers -
peer-synchronize -
commit-synchronize-server
-
Valider une configuration d’appareil
Pour enregistrer les modifications de configuration de l’appareil dans la base de données de configuration et pour activer la configuration sur l’appareil, utilisez la commande mode configuration commit . Vous pouvez émettre la commande à partir de n’importe commit quel niveau hiérarchique :
[edit]
user@host# commit
commit complete
[edit]
user@host#
Lorsque vous entrez la commit commande, la 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 opérationnelle actuelle de l’appareil.
Il est déconseillé d’effectuer une opération de validation sur le moteur de routage de secours lorsque le basculement du moteur de routage gracieux 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 la validation.
-
La configuration candidate que vous essayez de valider est supérieure à 700 Mo.
-
La configuration est verrouillée par un utilisateur qui a saisi la
configure exclusivecommande.
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 :
[editedit-path] ‘offending-statement;’error-message
Par exemple :
[edit firewall filter login-allowed term allowed from] ‘icmp-type [ echo-request echo-reply ];’ keyword ‘echo-reply’ unrecognized
Vous devez corriger l’erreur avant de revalider 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 candidat non validé est /var/rundb/juniper.db. Par défaut, la taille du fichier est limitée à la taille maximale par défaut de la base de données de configuration. Vous pouvez vérifier la taille de la base de données sur le disque et la taille maximale de la base de données en exécutant la show system configuration database usage commande. Vous pouvez également afficher la taille du fichier à partir du mode configuration en exécutant la run file list /var/rundb detail commande. Si la configuration candidate dépasse la taille maximale de la base de données, la validation échoue avec le message configuration database size limit exceeded. Pour corriger l’erreur, vous pouvez :
-
Augmentez la taille maximale de la base de données de configuration en configurant l’instruction
extend-sizeau niveau de la hiérarchie sur les[edit system configuration-database]appareils qui prennent en charge cette instruction. Vous devez redémarrer l’appareil pour que la modification soit effective. -
Simplifiez la configuration et réduisez 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.
Après avoir validé la configuration et, si nécessaire, redémarré, vous pouvez vérifier les mises à jour de la taille de la base de données sur le disque ou de la taille maximale de la base de données en exécutant la show system configuration database usage commande.
Les avertissements de validation de la CLI affichés pour les modifications de configuration au niveau de la [edit interfaces] hiérarchie sont supprimés et sont 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.
-
Il est déconseillé d’effectuer une opération de validation sur le moteur de routage de secours lorsque le basculement du moteur de routage gracieux est activé sur l’appareil.
-
Si vous configurez la même adresse IP pour une interface de gestion ou une interface interne telle que
re0:mgmt-0et une interface physique externe telle quexe-0/0/1, lorsque le basculement GRES (Graceful moteur de routage switchover) est activé, le 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 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 Logiciels
Jusqu’à 32 utilisateurs peuvent être en mode configuration et apporter simultanément des modifications à la configuration. Toutes les modifications apportées par tous les utilisateurs sont visibles par tous ceux 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, telle que set, editou delete.
Lorsque l’un des utilisateurs qui modifient la configuration émet une commit commande, la CLI vérifie et active toutes les modifications apportées par tous les utilisateurs.
Si vous entrez en mode configuration avec la configure private commande, chaque utilisateur dispose d’une configuration candidate privée à modifier indépendamment des autres utilisateurs. Lorsque vous validez la configuration, la CLI 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 sont 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 puis 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 candidate tant que vous restez en mode configuration. Cela vous permet d’apporter des modifications sans interférence d’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 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 en 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 configure exclusive le mode, l’utilisateur X peut alors valider les modifications apportées en configure private mode ou configure .
Présentation de la préparation et de l’activation des validations
Vous pouvez terminer le processus de validation en deux étapes. La fonctionnalité 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 validation après la préparation de la validation, mais vous recevrez un message indiquant que la validation est en attente d’activation.
Dans la première étape, 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 la deuxième étape, l’étape d’activation, la configuration préalablement préparée est activée. Ensuite, si vous devez 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é une fois la validation en attente effacée.
Nous vous recommandons de ne pas modifier la configuration entre les étapes 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 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 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é est applicable aux périphériques multichâssis, mais elle ne s’applique pas aux commits 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>
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 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 avec les fichiers nécessaires sont générées. 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écédemment préparée est activée et devient la configuration opérationnelle actuelle de l’appareil.
Pour préparer la configuration :
Pour activer la configuration préparée :
Utilisez la
commit activatecommande[edit] user@host#
commit activateLe message
commit completes’affiche.Pour vérifier la configuration du système activée, utilisez la commande suivante :
user@host>
show configuration system scriptslanguage python;
Pour vérifier la sortie des show system commit commandes et show system commit revision detail après commit activate est émise, exécutez les commandes suivantes.
user@host> show system commit
0 2018-07-12 22:54:46 PDT by user via cli commit activate
user@host> show system commit revision detail
Revision: re0-1499925285-2214
User : user
Client : cli
Time : 2018-07-12 22:54:46 PDT
Comment : commit activate
Activer 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’appareil revient automatiquement à la configuration précédente et rétablit l’accès une fois le délai de confirmation de restauration écoulé. Cette fonctionnalité est appelée restauration automatique.
Pour valider la configuration candidate actuelle, mais exiger une confirmation explicite pour que la validation devienne permanente, utilisez la commit confirmed commande du mode de configuration :
[edit]
user@host# commit confirmed
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
#commit confirmed will be rolled back in 10 minutes
[edit]
user@host#
Une fois que vous avez vérifié que la modification fonctionne correctement, vous pouvez garder la nouvelle configuration active en entrant une commande ou commit check dans les commit 10 minutes suivant la commit confirmed commande. Par exemple :
[edit]
user@host# commit check
configuration check succeeds
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 :
user@host>show system commit
0 2018-01-05 15:00:37 PST by root via cli commit confirmed, rollback in 3mins
Comme la commit commande, la commit confirmed commande vérifie la syntaxe de configuration et signale les erreurs. 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.
Pour modifier le délai avant de devoir confirmer la nouvelle configuration, spécifiez le nombre de minutes pendant lesquelles vous exécutez la commande :
[edit]
user@host# commit confirmed minutes
commit complete
[edit]
user@host#
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 candidate devienne active. Pour enregistrer les modifications apportées à la configuration de l’appareil et activer la configuration sur l’appareil ultérieurement ou au redémarrage, utilisez la commit at commande configuration mode, spécifiant reboot ou une heure ultérieure au niveau de la hiérarchie [edit] :
[edit]
user@host # commit at string
string est reboot ou l’heure future d’activer les changements de configuration. Vous pouvez spécifier l’heure dans deux formats :
Une valeur de temps au format
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 commande decommit atmode de configuration est émise. Utilisez l’heure de 24 heures pour lahhvaleur ; par exemple,04:30:00est 4:30:00 AM et20:00est 8:00 PM. L’heure est interprétée en fonction des paramètres d’horloge et de fuseau horaire sur le routeur.Une valeur de date et d’heure au format
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’émission de lacommit atcommande. Utilisez 24 heures pour lahhvaleur. Par exemple,2018-08-2112:30:00il est 12h30 le 21 août 2018. L’heure est interprétée en fonction des paramètres d’horloge et de fuseau horaire sur le routeur.
Placer 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 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.
Si le logiciel de l’appareil tombe en panne 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 l’avoir request system reboot émise.
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, consultez l’explorateurclear CLI.
Il est déconseillé d’effectuer une opération de validation sur le moteur de routage de secours lorsque le basculement du moteur de routage gracieux 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 :
user@host# commit | display detail
Par exemple :
[edit]
user@host# commit | display detail2021-10-08 10:33:42.619908 PDT: Obtaining lock for commit
2021-10-08 10:42:36.341266 PDT: Obtaining lock for commit
2021-10-08 10:42:36.343401 PDT: updating commit revision
2021-10-08 10:42:36.343639 PDT: UI extensions feature is not configured
2021-10-08 10:42:36.343718 PDT: UI change-notification feature is not configured
2021-10-08 10:42:36.343877 PDT: Started running translation script
2021-10-08 10:42:36.398596 PDT: No delta input for translation
2021-10-08 10:42:36.398679 PDT: Finished running translation script
2021-10-08 10:42:36.398904 PDT: start loading commit script changes
2021-10-08 10:42:36.398944 PDT: no commit script changes
2021-10-08 10:42:36.399006 PDT: no transient commit script changes
2021-10-08 10:42:36.399046 PDT: finished loading commit script changes
2021-10-08 10:42:36.399091 PDT: No translation output from the scripts
2021-10-08 10:42:36.400007 PDT: building groups inheritance path proportional in
candidate db
2021-10-08 10:42:36.400074 PDT: finished groups inheritance path
2021-10-08 10:42:36.400112 PDT: copying juniper.db to juniper.data+
2021-10-08 10:42:36.402278 PDT: finished copying juniper.db to juniper.data+
2021-10-08 10:42:36.402357 PDT: exporting juniper.conf
2021-10-08 10:42:36.404504 PDT: expanding interface-ranges
2021-10-08 10:42:36.404566 PDT: finished expanding interface-ranges
2021-10-08 10:42:36.404598 PDT: setup foreign files
2021-10-08 10:42:36.411776 PDT: propagating foreign files
2021-10-08 10:42:36.411824 PDT: Sending constraint check command to evaluate con
straints
2021-10-08 10:42:36.580667 PDT: constraints passed in mustd - not checking const
raints in propagation
2021-10-08 10:42:36.586908 PDT: complete foreign files
2021-10-08 10:42:36.663944 PDT: Forking child for configd-streamer operation
2021-10-08 10:42:36.666585 PDT: dropping unchanged foreign files
2021-10-08 10:42:36.666768 PDT: start ffp propagate
2021-10-08 10:42:36.855945 PDT: propagate stp-portid-ffp
2021-10-08 10:42:37.120224 PDT: propagate stp-portid-ffp done
2021-10-08 10:42:37.120447 PDT: propagate interface-alias-ffp
2021-10-08 10:42:37.464777 PDT: propagate interface-alias-ffp done
2021-10-08 10:42:37.467692 PDT: finish ffp propagate
2021-10-08 10:42:37.467826 PDT: Sending command to evaluate validation hooks
2021-10-08 10:42:37.471143 PDT: daemons checking new configuration
2021-10-08 10:42:37.761146 PDT: Collecting status of mustd hooks validation, sta
tus 0
2021-10-08 10:42:37.761273 PDT: commit wrapup...
2021-10-08 10:42:37.761519 PDT: Checking status of configd-streamer child before
ffp activate
2021-10-08 10:42:37.761562 PDT: ev.ops+ file generated successfully
2021-10-08 10:42:37.761635 PDT: start ffp activate
2021-10-08 10:42:37.938324 PDT: activate stp-portid-ffp
2021-10-08 10:42:38.181781 PDT: activate stp-portid-ffp done
2021-10-08 10:42:38.181953 PDT: activate interface-alias-ffp
2021-10-08 10:42:38.373063 PDT: activate interface-alias-ffp done
2021-10-08 10:42:38.373125 PDT: activate hostname-ffp
2021-10-08 10:42:38.731220 PDT: activate hostname-ffp done
2021-10-08 10:42:38.731575 PDT: activate configd-ffp
2021-10-08 10:42:38.904529 PDT: activate configd-ffp done
2021-10-08 10:42:38.906425 PDT: activating '/var/etc/cosd.conf'
2021-10-08 10:42:38.906598 PDT: activating '/var/etc/pam.conf'
2021-10-08 10:42:38.906716 PDT: activating '/var/etc/pam_radius.conf'
2021-10-08 10:42:38.983913 PDT: activating '/var/etc/pam_tacplus.conf'
2021-10-08 10:42:38.984100 PDT: activating '/var/etc/issue'
2021-10-08 10:42:38.984202 PDT: activating '/var/etc/certs'
2021-10-08 10:42:38.991939 PDT: activating '/var/etc/motd'
2021-10-08 10:42:38.992178 PDT: activating '/var/etc/max-db-size-cfg'
2021-10-08 10:42:38.992267 PDT: activating '/var/etc/subs-mgmt-cfg'
2021-10-08 10:42:38.992342 PDT: activating '/var/etc/nc_notification'
2021-10-08 10:42:38.992464 PDT: activating '/var/etc/ephinst.conf'
2021-10-08 10:42:38.992557 PDT: activating '/var/etc/config-apps.txt'
2021-10-08 10:42:38.992674 PDT: executing foreign_commands
2021-10-08 10:42:38.992722 PDT: /bin/sh /etc/rc.ui ui_setup_users (sh)
2021-10-08 10:42:39.24126 PDT: not executing commit in cli_sysctl
2021-10-08 10:42:39.24234 PDT: finish ffp activate
2021-10-08 10:42:39.24278 PDT: db_groups_info_clear start
2021-10-08 10:42:39.419569 PDT: db_groups_info_clear done
2021-10-08 10:42:39.419653 PDT: activating '/var/rundb/juniper.data'
2021-10-08 10:42:40.14698 PDT: Rotate backup configs
2021-10-08 10:42:40.142039 PDT: ssync begins
2021-10-08 10:42:40.566324 PDT: ssync ends
2021-10-08 10:42:40.566392 PDT: ssync begins
2021-10-08 10:42:40.807541 PDT: ssync ends
2021-10-08 10:42:40.807608 PDT: notifying daemons of new configuration
2021-10-08 10:42:40.807804 PDT: ssync begins
2021-10-08 10:42:40.924440 PDT: ssync ends
2021-10-08 10:42:40.924630 PDT: mgd tracing: disabled
2021-10-08 10:42:40.924684 PDT: New database revision 're0-1633714956-29' and ol
d database revision 're0-1633714422-28'
2021-10-08 10:42:40.924709 PDT: commit complete
commit complete
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 la commit comment déclaration. Le commentaire peut comporter jusqu’à 512 caractères et vous devez le taper sur une seule ligne.
[edit]
user@host# commit comment comment-string
comment-string est le texte du commentaire.
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 :
[edit]
user@host# commit comment "add user joe"
commit complete
[edit]
user@host#
Pour ajouter un commentaire à la commit confirmed commande, incluez l’instruction comment après la commit confirmed commande :
[edit]
user@host# commit confirmed comment "add customer to port 27"
commit confirmed will be automatically rolled back in 10 minutes unless confirmed
commit complete
[edit]
user@host#
Pour afficher ces commentaires de validation, exécutez la show system commit commande mode opérationnel.
Vous pouvez également utiliser la commit confirmed commande en [edit private] mode configuration.
À compter de la version 24.2R1 de Junos OS, Junos OS vous oblige à publier un commentaire pour chaque demande de validation. Cela permet de suivre les modifications apportées par plusieurs utilisateurs ou administrateurs au moment de la validation.
La commit commande ne s’exécute pas sans l’argument comment .
Pour obliger l’utilisateur à ajouter un commentaire pour chaque demande de validation, configurez force-commit-log l’option au niveau de la [edit system commit] hiérarchie.
Présentation des validations par lots
La validation par lots agrège ou fusionne plusieurs modifications de configuration à partir de sessions ou d’utilisateurs CLI différents 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é 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 par lots pour la session suivante de l’opération de validation par lots. Les lots sont créés jusqu’à ce qu’il ne reste plus d’entrées de commit dans le répertoire de file d’attente.
Par rapport à l’opération de validation normale où toutes les validations sont validées indépendamment séquentiellement, 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 commit 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 chargement dans l’un des travaux agrégés, le travail de validation qui rencontre l’erreur est ignoré et les travaux restants sont agrégés et validés.
Par exemple, s’il y a cinq tâches de validation (commit-1, commit-4commit-2commit-3et commit-5) en cours d’agrégation et commit-3 rencontrent une erreur lors du chargement, commit-3 sont ignorées et commit-1, commit-2commit-4et commit-5 sont agrégées et validées.
S’il y a une erreur lors de l’opération de validation lorsque deux travaux ou plus sont agrégés et validés, l’agrégation est ignorée et chacun de ces travaux est validé individuellement comme une opération de validation normale.
Par exemple, s’il existe cinq tâches de validation (commit-1, commit-2, commit-3commit-4, et commit-5) qui sont agrégées et qu’une erreur de validation est causée par , commit-3l’agrégation est ignorée, commit-1, commit-3commit-2commit-4et commit-5 sont validées individuellement, et que la CLI 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.
Vue d’ensemble
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 travaux de validation agrégés ou fusionnés en un seul commit par lots, le nombre maximal de travaux pouvant être ajoutés à 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.
La configuration
- Configuration rapide de la CLI
- Configuration des propriétés du serveur de validation
- Validation de la configuration à partir du mode de configuration par lots
Configuration rapide de la 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 qu’ils correspondent à 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
set system commit server maximum-aggregate-pool 4set system commit server maximum-entries 500set system commit server commit-interval 5set system commit server days-to-keep-error-logs 30set system commit server traceoptions file commitd_novset system commit server traceoptions flag all
Configuration des propriétés du serveur de validation
Procédure étape par étape
-
(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-pool5.Remarque :Paramètre
maximum-aggregate-poolsur1Commit chacun des travaux individuellement.Dans cet exemple, le nombre de transactions de validation est défini sur
4indiquant 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.[edit system commit server]user@R0#set maximum-aggregate-pool 4 -
(Facultatif) Configurez le nombre maximal de travaux autorisés dans un lot.
Cela limite le nombre de tâches de validation ajoutées à la file d’attente.
[edit system commit server]user@R0#set maximum-entries 500Remarque :Si vous définissez
maximum-entriesla valeur ,1le serveur de validation ne peut pas ajouter plus d’une tâche à la file d’attente et la CLI affiche un message approprié lorsque vous essayez de valider plusieurs tâches. -
(Facultatif) Configurez le temps (en secondes) d’attente avant de démarrer l’opération de validation par lots suivante.
[edit system commit server]user@R0#set commit-interval 5 -
(Facultatif) Configurez le nombre de jours pour conserver les journaux d’erreurs.
La valeur par défaut est
30days.[edit system commit server]user@R0#set days-to-keep-error-logs 30 -
(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.[edit system commit server]user@R0#set traceoptions commitd_novuser@R0#set traceoptions flag all
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.
user@R0# show system commit server
maximum-aggregate-pool 4;
maximum-entries 500;
commit-interval 5;
days-to-keep-error-logs 30;
traceoptions {
file commitd_nov;
flag all;
}
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 entrez
commit.[edit batch]user@R0#commitAdded to commit queue request-id: 1000 -
Pour attribuer une priorité plus élevée à une tâche de validation par lots, exécutez la
commitcommande avec l’optionpriority.[edit batch]user@R0#commit priorityAdded to commit queue request-id: 1001 -
Pour valider une configuration sans agréger les modifications de configuration avec d’autres travaux de validation dans la file d’attente, exécutez la
commitcommande avec l’optionatomic.[edit batch]user@R0#commit atomicAdded to commit queue request-id: 1002 -
Pour valider une configuration sans agréger les modifications de configuration avec d’autres tâches de validation dans la file d’attente et accorder une priorité plus élevée à la tâche de validation, exécutez la
commitcommande avec l’optionatomic priority.[edit batch]user@R0#commit atomic priorityAdded to commit queue request-id: 1003
Vérification
Vérifiez que la configuration fonctionne correctement.
- Vérification de l’état du serveur de validation par lots
- Vérification de l’état de la validation par lots
- Affichage des fichiers de correctifs dans une tâche de validation par lots
- Affichage des fichiers de trace pour les opérations de validation par lots
Vérification de l’état du serveur de validation par lots
Objet
Vérifiez l’état du serveur de validation par lots.
Mesures à prendre
user@R0> show system commit server
Commit server status : Not running
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.
user@R0> show system commit server
Commit server status : Running
Jobs in process:
1003 1004 1005
Signification
Le Jobs in process champ répertorie les ID de validation des tâches en cours.
Vérification de l’état de la validation par lots
Objet
Vérifiez l’état des validations par lots dans la file d’attente du serveur de validation.
Mesures à prendre
user@R0> show system commit server queue
Pending commits:
Id: 1005
Last Modified: Tue Nov 1 23:56:43 2018
Completed commits:
Id: 1000
Last Modified: Tue Nov 1 22:46:43 2018
Status: Successfully committed 1000
Id: 1002
Last Modified: Tue Nov 1 22:50:35 2018
Status: Successfully committed 1002
Id: 1004
Last Modified: Tue Nov 1 22:51:48 2018
Status: Successfully committed 1004
Id: 1007
Last Modified: Wed Nov 2 01:08:04 2018
Status: Successfully committed 1007
Id: 1009
Last Modified: Wed Nov 2 01:16:45 2018
Status: Successfully committed 1009
Id: 1010
Last Modified: Wed Nov 2 01:19:25 2018
Status: Successfully committed 1010
Id: 1011
Last Modified: Wed Nov 2 01:28:16 2018
Status: Successfully committed 1011
Error commits:
Id: 1008
Last Modified: Wed Nov 2 01:08:18 2018
Status: Error while commiting 1008
Signification
Pending commits Affiche les travaux de validation qui sont ajoutés à la file d’attente de validation mais qui ne le sont pas encore. Completed commits Affiche la liste des travaux de validation qui réussissent. Error commits sont des commits qui ont échoué à cause d’une erreur.
Affichage des fichiers de correctifs dans une tâche de validation par lots
Objet
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 lot.
Mesures à prendre
-
Utilisez la
show system commit server queue patchcommande pour afficher les correctifs de toutes les opérations de validation.user@R0>
show system commit server queue patchPending commits: none Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit groups] re1 { ... } + GRP-DHCP-POOL-NOACCESS { + access { + address-assignment { + pool <*> { + family inet { + dhcp-attributes { + maximum-lease-time 300; + grace-period 300; + domain-name verizon.net; + name-server { + 4.4.4.1; + 4.4.4.2; + } + } + } + } + } + } + } Id: 1002 Last Modified: Tue Nov 1 22:50:35 2018 Status: Successfully committed 1002 Patch: [edit] + snmp { + community abc; + } Id: 1010 Last Modified: Wed Nov 2 01:19:25 2018 Status: Successfully committed 1010 Patch: [edit system syslog] file test { ... } + file j { + any any; + } Error commits: Id: 1008 Last Modified: Wed Nov 2 01:08:18 2018 Status: Error while commiting 1008 Patch: [edit system] + radius-server { + 10.1.1.1 port 222; + }La sortie affiche les changements de configuration pour chaque ID de travail de validation.
-
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.user@R0>
show system commit server queue patch id 1000Completed commits: Id: 1000 Last Modified: Tue Nov 1 22:46:43 2018 Status: Successfully committed 1000 Patch: [edit system] + radius-server { + 192.168.69.162 secret teH.bTc/RVbPM; + 192.168.64.10 secret teH.bTc/RVbPM; + 192.168.60.52 secret teH.bTc/RVbPM; + 192.168.60.55 secret teH.bTc/RVbPM; + 192.168.4.240 secret teH.bTc/RVbPM; + }
Signification
La sortie affiche le patch créé pour une tâche de validation. Le + signe ou - indique les modifications apportées à la configuration d’un travail de validation spécifique.
Affichage des fichiers de trace pour les opérations de validation par lots
Objet
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.
Mesures à prendre
-
Utilisez la
file show /var/log/<filename>commande pour afficher toutes les entrées du fichier journal.user@R0>
file show/var/log/commitd_novLa sortie affiche les journaux des événements du serveur de validation et d’autres journaux pour les validations par lots.
Nov 1 22:46:43 Successfully committed 1000 Nov 1 22:46:43 pausing after commit for 0 seconds ... Nov 1 22:46:43 Done working on queue ... Nov 1 22:47:17 maximum-aggregate-pool = 5 Nov 1 22:47:17 maximum-entries= 0 Nov 1 22:47:17 asynchronous-prompt = no Nov 1 22:47:17 commit-interval = 0 Nov 1 22:47:17 days-to-keep-error-logs = -1 ... Nov 1 22:47:17 Added to commit queue request-id: 1001 Nov 1 22:47:17 Commit server status=running Nov 1 22:47:17 No need to pause ... Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:47:18 doing rollback ...
-
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 committedpipe.La sortie affiche les ID de travail de validation par lots pour les opérations de validation réussies.
user@R0>
file show/var/log/commitd_nov | match committedNov 1 22:46:43 Successfully committed 1000 Nov 1 22:50:35 Successfully committed 1002 Nov 1 22:51:48 Successfully committed 1004 Nov 2 01:08:04 Successfully committed 1007 Nov 2 01:16:45 Successfully committed 1009 Nov 2 01:19:25 Successfully committed 1010 Nov 2 01:28:16 Successfully committed 1011 -
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”pipe.La sortie affiche les ID de travail de validation pour les opérations de validation ayant échoué.
user@R0>
file show/var/log/commitd_nov | match “Error while”Nov 1 22:47:18 Error while commiting 1001 Nov 1 22:51:10 Error while commiting 1003 Nov 1 22:52:15 Error while commiting 1005 ... -
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 pipe| match “commit server”.La sortie affiche les journaux des événements du serveur de validation.
user@R0>
file show/var/log/commitd_nov | match “commit server”Nov 1 22:46:39 Commit server status=running Nov 1 22:46:39 Commit server jobs=1000 Nov 1 22:46:43 Commit server status=not running Nov 1 22:46:43 Commit server jobs= Nov 1 22:47:17 Commit server status=running Nov 1 22:47:18 Commit server jobs=1001 Nov 1 22:47:18 2 errors reported by commit server Nov 1 22:47:18 Commit server status=not running Nov 1 22:47:18 Commit server jobs= Nov 1 22:50:31 Commit server status=running Nov 1 22:50:31 Commit server jobs=1002 Nov 1 22:50:35 Commit server status=not running Nov 1 22:50:35 Commit server jobs= Nov 1 22:51:09 Commit server status=running Nov 1 22:51:10 Commit server jobs=1003 Nov 1 22:51:10 2 errors reported by commit server Nov 1 22:51:10 Commit server status=not running ...
Sauvegardez la configuration validée sur l’autre lecteur de démarrage
Une fois que vous avez validé la configuration et que vous êtes satisfait qu’elle s’exécute correctement, vous devez lancer la request system snapshot commande pour sauvegarder le nouveau logiciel sur le système de /altconfig fichiers. Si vous n’exécutez pas la request system snapshot commande, la configuration sur le lecteur de démarrage secondaire n’est pas synchronisée avec la configuration sur le lecteur de démarrage principal.
La request system snapshot commande sauvegarde le système de fichiers racine sur /altroot, et /config sur /altconfig. Les systèmes racine et /config de fichiers se trouvent sur la clé USB du routeur, et les /altroot systèmes de fichiers se /altconfig trouvent sur le disque dur du routeur (si disponible).
Après avoir lancé 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.