<commit-configuration>

Utilisation

Description

Demandez au serveur de protocole XML NETCONF ou Junos d’exécuter l’une des variantes de l’opération de validation sur la configuration candidate, une copie privée de la configuration candidate ou une instance ouverte de la base de données de configuration éphémère.

Certaines restrictions s’appliquent à l’opération de validation d’une copie privée de la configuration candidate et à la base de données de configuration éphémère. Par exemple, l’opération de validation échoue pour une copie privée si la configuration candidate normale est verrouillée par un autre utilisateur ou application ou si elle inclut des modifications non validées effectuées depuis la création de la copie privée. En outre, une opération de validation sur une instance de la base de données de configuration éphémère prend uniquement en charge l’option <synchronize/> .

Placez la balise appropriée dans l’élément tag pour spécifier le type d’opération <commit-configuration> de validation :

• Pour valider la configuration immédiatement, ce qui en fait la configuration active sur l’appareil, émettez la balise vide <commit-configuration/> .

• Pour vérifier l’exactitude syntaxique de la configuration candidate ou d’une copie privée sans la valider réellement, placez la <check/> balise dans l’élément <commit-configuration> tag.

• Pour enregistrer un message dans le journal de l’historique des validations lorsque l’opération de validation associée réussit, définissez la chaîne de message du journal dans l’élément tag et placez l’élément tag dans l’élément <log> <commit-configuration> tag. L’élément <log> tag peut être combiné avec n’importe quel autre élément tag. Lorsque l’élément tag est émis seul, l’opération <log> de validation associée commence immédiatement.

• Pour valider la configuration candidate mais exiger une confirmation explicite pour que la validation devienne permanente, placez la <confirmed/> balise dans l’élément <commit-configuration> tag.

  Si la validation n’est pas confirmée, la configuration revient à la configuration précédente après un court laps de temps. Par défaut, la restauration se produit après 10 minutes. Pour définir un délai de restauration différent, incluez l’élément <confirm-timeout> tag et spécifiez une valeur comprise entre 1 et 65 535 minutes. Pour retarder à nouveau la restauration (après l’échéance de restauration d’origine), émettez la balise (incluse dans l’élément tag) avant l’expiration de la date limite et, éventuellement, incluez l’élément <commit-configuration> <confirm-timeout> pour spécifier un délai différent de la <confirmed/> valeur par défaut. La restauration peut être retardée à plusieurs reprises de cette manière.

  Pour valider la configuration immédiatement et définitivement après l’émission de la balise, émettez la balise vide <commit-configuration/> ou les balises avant l’expiration <confirmed/> <commit-configuration><check/><commit-configuration> du délai de restauration. L’appareil valide la configuration candidate et annule la restauration. Si la configuration candidate est toujours identique à la configuration validée actuelle, l’effet est le même que la réinitialisation de la configuration validée actuelle.

  Note:

  L’opération de validation confirmée n’est pas disponible lors de la validation d’une copie privée de la configuration ou d’une instance ouverte de la base de données de configuration éphémère.

• Sur un appareil doté de deux moteurs de routage, validez la configuration candidate, la copie privée ou l’instance de base de données éphémère stockée sur le moteur de routage local des deux moteurs de routage. Combinez les éléments de balise comme indiqué ci-dessous (la base de données éphémère ne prend en charge que l’option <synchronize/> ) :

  • Pour copier la configuration candidate ou les données de configuration de l’instance éphémère ouverte stockée sur le moteur de routage local vers l’autre moteur de routage, vérifier l’exactitude syntaxique de la configuration et la valider immédiatement sur les deux moteurs de routage, placez la <synchronize/> balise dans l’élément <commit-configuration> tag.

  • Pour copier la configuration candidate stockée sur le moteur de routage local vers l’autre moteur de routage, vérifier l’exactitude syntaxique du candidat et la valider sur les deux moteurs de routage à une date ultérieure définie, placez la balise or <force-synchronize/> et <at-time> les <synchronize/> éléments de balise dans l’élément <commit-configuration> de balise. Définissez la valeur dans l’élément tag comme décrit précédemment pour l’utilisation de l’élément <at-time> <at-time> tag seul.

  • Pour copier la configuration candidate stockée sur le moteur de routage local vers l’autre moteur de routage et vérifier l’exactitude syntaxique du candidat sur chaque moteur de routage, placez les <synchronize/> éléments or <force-synchronize/> et <check/> tag dans l’élément <commit-configuration> tag.

  • Pour copier la configuration candidate stockée sur le moteur de routage local vers l’autre moteur de routage, vérifiez l’exactitude syntaxique du candidat et validez-la sur les deux moteurs de routage mais nécessitent une confirmation, placez la balise et les éléments de balise, et <confirmed/> éventuellement l’élément de balise, dans l’élément <commit-configuration> <confirm-timeout> de <synchronize/> balise. Définissez la valeur dans l’élément tag comme décrit précédemment pour l’utilisation de la balise et <confirm-timeout> de l’élément <confirm-timeout> <confirmed/> balise seule.

  • Pour forcer la réussite de la même opération de validation synchronisée que celle appelée par la balise, même s’il existe des sessions de configuration ouvertes ou des modifications de configuration non validées sur la machine distante, placez la <synchronize/> <force-synchronize/> balise dans l’élément <commit-configuration> tag.

• Pour planifier ultérieurement la configuration candidate pour validation, placez l’élément tag dans l’élément <at-time> <commit-configuration> tag. Il existe trois types valides de spécificateurs de temps :

  • La chaîne reboot, pour valider la configuration au prochain redémarrage du périphérique.

  • Valeur d’heure de la forme hh:[ :ss] (heures, minutes et, éventuellement, secondes), pour valider la configuration à l’heure spécifiée, qui doit être dans le futur mais avant 23 :59 :59 le jour où l’élément <commit-configuration> tagmm est émis. Utilisez l’heure de 24 heures pour la hh valeur ; par exemple, 04 :30 :00 signifie 4 :30 :00 AM et 20 :00 signifie 8 :00 PM. L’heure est interprétée en fonction des paramètres de l’horloge et du fuseau horaire de l’appareil.

  • Valeur de date et d’heure du formulaire yyyy--dd hhmm :[ :mmss] (année, mois, date, heures, minutes et, éventuellement, secondes), pour valider la configuration à la date et à l’heure spécifiées, qui doivent être postérieures à l’émission de l’élément <commit-configuration> tag. Utilisez l’heure de 24 heures pour la hh valeur. Par exemple, 2005-08-21 15 :30 :00 signifie 15 :30 le 21 août 2005. L’heure est interprétée en fonction des paramètres de l’horloge et du fuseau horaire de l’appareil.

    Note:

    L’heure que vous spécifiez doit être postérieure de plus de 1 minute à l’heure actuelle sur l’appareil.

    La configuration est immédiatement vérifiée pour l’exactitude syntaxique. Si la vérification réussit, la validation est planifiée pour la configuration à l’heure spécifiée. Si la vérification échoue, l’opération de validation n’est pas planifiée.

Contenu

<at-time>	Planifiez l’opération de validation pour une date ultérieure spécifiée.
<check>	Demandez à vérifier que la configuration est syntaxiquement correcte, mais ne la validez pas réellement.
<confirmed>	Demandez une validation de la configuration candidate et exigez une confirmation explicite pour que la validation devienne permanente. Si la validation n’est pas confirmée, restaurez la configuration précédente après un court laps de temps, 10 minutes par défaut. Utilisez l’élément <confirm-timeout> tag pour spécifier une durée différente.
<confirm-timeout>	Spécifiez le nombre de minutes pendant lesquelles la configuration reste active lorsque la <confirmed/> balise est incluse dans l’élément <commit-configuration> tag. Autonomie : 1 à 65 535 minutes Valeur par défaut : 10 minutes
<log>	Enregistrez un message dans le journal de l’historique des validations lorsque l’opération de validation réussit.
<synchronize>	Sur les systèmes à double plan de contrôle, demandez que la configuration d’un plan de contrôle soit copiée sur l’autre plan de contrôle, vérifiée pour la syntaxe correcte et validée sur les deux moteurs de routage.
<force-synchronize>	Sur les systèmes à double plan de contrôle, forcez la configuration candidate sur un plan de contrôle à copier dans l’autre plan de contrôle.

Informations sur la version

Il s’agit d’une opération du protocole de gestion XML Junos. Il est pris en charge dans les sessions de protocole XML Junos, et il est pris en charge en tant qu’extension propriétaire de Juniper Networks dans les sessions NETCONF sur les appareils exécutant Junos OS qui identifient l’URI http://xml.juniper.net/netconf/junos/1.0 dans l’échange de fonctionnalités.