Valider la configuration du candidat uniquement après confirmation à l’aide de NETCONF
Lorsque vous validez la configuration du candidat sur un équipement exécutant Junos OS, elle devient la configuration active sur la plate-forme de routage, de commutation ou de sécurité. Pour obtenir des informations plus détaillées sur les opérations de validation, y compris une discussion sur l’interaction entre les différentes variantes de l’opération, consultez le guide de l’utilisateur CLI
Lorsque vous validez la configuration du candidat, vous pouvez exiger une confirmation explicite pour que la validation devienne permanente. L’opération de validation confirmée est utile pour vérifier qu’une modification de configuration fonctionne correctement et n’empêche pas la direction d’accéder à l’équipement. Si la modification empêche l’accès ou provoque d’autres erreurs, la restauration automatique vers la configuration précédente restaure l’accès après la date limite de restauration. Si la validation n’est pas confirmée dans le délai spécifié, soit 600 secondes (10 minutes) par défaut, l’équipement charge et valide automatiquement la configuration précédemment validée.
Dans une session NETCONF avec un équipement exécutant Junos OS, pour valider la configuration du candidat mais exiger une confirmation explicite pour que la validation devienne permanente, une application cliente enferme la balise vide <confirmed/>
dans les éléments et <rpc>
de <commit>
balise.
<rpc> <commit> <confirmed/> </commit> </rpc> ]]>]]>
Pour spécifier un nombre de secondes pour la date limite de restauration qui est différente de la valeur par défaut de 600 secondes, l’application inclut l’élément <confirm-timeout>
de balise et spécifie le nombre de secondes pour le délai de restauration, entre 1 et 4 294 967 295 secondes.
<rpc> <commit> <confirmed/> <confirm-timeout>rollback-delay</confirm-timeout> </commit> </rpc> ]]>]]>
Vous ne pouvez pas effectuer une opération de validation confirmée sur une instance de la base de données de configuration éphémère.
Dans les deux cas, le serveur NETCONF confirme qu’il a engagé temporairement la configuration du candidat en renvoyant la <ok/>
balise dans le .<rpc-reply>
<rpc-reply xmlns="URN" xmlns:junos="URL"> <ok/> </rpc-reply> ]]>]]>
Si le serveur NETCONF ne peut pas valider la configuration du candidat, l’élément contient à la <rpc-reply>
place un <rpc-error>
élément expliquant la raison de l’échec. Les causes les plus courantes sont des erreurs sémantiques ou syntaxiques dans la configuration du candidat.
Pour repousser la date limite de restauration actuelle, l’application cliente émet à nouveau la <confirmed/>
balise d’un <commit>
élément de balise avant que la date limite ne soit passée. Si vous le souhaitez, il inclut l’élément <confirm-timeout>
qui spécifie la durée de la restauration suivante ; omettez l’élément de balise pour retarder la restauration par défaut de 600 secondes (10 minutes). L’application cliente peut retarder indéfiniment la restauration en émettant la <confirmed/>
balise de cette manière de manière répétée.
Pour valider la configuration de manière permanente, l’application cliente émet la <commit/>
balise jointe à un élément de <rpc>
balise avant que la date limite de restauration ne soit passée. La restauration est annulée et la configuration du candidat est validée immédiatement, comme décrit dans Valider la configuration du candidat à l’aide de NETCONF. Si la configuration du candidat est toujours la même que la configuration temporairement validée, cette configuration réengage effectivement la configuration temporairement engagée.
Si une autre application utilise l’élément <kill-session/>
de balise pour mettre fin à la session de cette application alors qu’une validation confirmée est en attente (cette application a validé des modifications mais ne les ont pas encore confirmées), le serveur NETCONF qui gère cette session restaure la configuration à son état avant l’émission de l’instruction de validation confirmée. Pour plus d’informations sur l’arrêt de session, voir Mettre fin à une session NETCONF.
L’exemple suivant montre comment valider la configuration du candidat avec un délai de restauration de 300 secondes.
Application cliente
<rpc> <commit> <confirmed/> <confirm-timeout>300</confirm-timeout> </commit> </rpc> ]]>]]>
Serveur NETCONF
<rpc-reply xmlns="URN" xmlns:junos="URL"> <ok/> </rpc-reply> ]]>]]>