Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Committing the Candidate Configuration Only After Confirmation Using the Junos XML Protocol

When you commit the candidate configuration on a device running Junos OS, it becomes the active configuration on the routing, switching, or security platform. For more detailed information about commit operations, including a discussion of the interaction among different variants of the operation, see the CLI User Guide

When you commit the candidate configuration, you can require an explicit confirmation for the commit to become permanent. The confirmed commit operation is useful for verifying that a configuration change works correctly and does not prevent management access to the device. If the change prevents access or causes other errors, the automatic rollback to the previous configuration restores access after the rollback deadline passes. If the commit is not confirmed within the specified amount of time, which is 10 minutes, the device automatically loads and commits (rolls back to) the previously committed configuration.

In a Junos XML protocol session with a device running Junos OS, to commit the candidate configuration but require an explicit confirmation for the commit to become permanent, a client application encloses the empty <confirmed/> tag in the <commit-configuration> and <rpc> tag elements.

To specify a number of minutes for the rollback deadline that is different from the default value of 10 minutes, the application includes the <confirm-timeout> tag element and specifies the number of minutes for the delay, in the range from 1 through 65,535 minutes.

Note:

You cannot perform a confirmed commit operation on a private copy of the configuration or on an instance of the ephemeral configuration database.

The Junos XML protocol server confirms that it committed the candidate configuration temporarily by returning the <rpc-reply>, <commit-results>, <output>, and <routing-engine> tag elements. If the initial commit operation succeeds, the <routing-engine> element encloses the <commit-success/> tag and the <name> tag element, which reports the name of the Routing Engine on which the commit operation succeeded (re0 on devices that use a single Routing Engine, and either re0 or re1 on devices that can have two Routing Engines).

If the Junos XML protocol server cannot commit the candidate configuration, the <rpc-reply> element instead encloses an <xnm:error> element explaining the reason for the failure. The most common causes are semantic or syntactic errors in the candidate configuration.

To delay the rollback to a time later than the current rollback deadline, the application emits the <confirmed/> tag in a <commit-configuration> tag element again before the deadline passes. Optionally, it can include the <confirm-timeout> element to specify how long to delay the next rollback; omit that tag element to delay the rollback by the default of 10 minutes. The client application can delay the rollback indefinitely by emitting the <confirmed/> tag repeatedly in this way.

To commit the configuration permanently, the client application emits one of the following tag sequences before the rollback deadline passes:

  • The <check/> tag enclosed in <commit-configuration> and <rpc> tag elements. The rollback is canceled and the candidate configuration is committed immediately.

  • The empty <commit-configuration/> tag enclosed in an <rpc> tag element.

    The rollback is canceled and the candidate configuration is committed immediately, as described in Committing the Candidate Configuration Using the Junos XML Protocol. If the candidate configuration is still the same as the temporarily committed configuration, this effectively recommits the temporarily committed configuration:

  • The <synchronize/> tag enclosed in <commit-configuration> and <rpc> tag elements.

    The rollback is canceled and the candidate configuration is checked and committed immediately on both Routing Engines, as described in Committing and Synchronizing a Configuration on Redundant Control Planes Using the Junos XML Protocol. If a confirmed commit operation has been performed on both Routing Engines, then emitting the <synchronize/> tag cancels the rollback on both.

  • The <at-time> tag element enclosed in <commit-configuration> and <rpc> tag elements.

    The rollback is canceled and the configuration is checked immediately for syntactic correctness, then committed at the scheduled time, as described in Committing a Configuration at a Specified Time Using the Junos XML Protocol.

The <confirmed/> and <confirm-timeout> tag elements can be combined with the <synchronize/> tag, the <log/> tag element, or both. For more information, seeCommitting and Synchronizing a Configuration on Redundant Control Planes Using the Junos XML Protocol and Logging a Message About a Commit Operation Using the Junos XML Protocol.

If another application uses the <kill-session/> tag element to terminate this application’s session while a confirmed commit is pending (this application has committed changes but not yet confirmed them), the Junos XML protocol server that is servicing this session restores the configuration to its state before the confirmed commit instruction was issued. For more information about session termination, see Terminating Junos XML Protocol Sessions.

The following example shows how to commit the candidate configuration on Routing Engine 1 with a rollback deadline of 20 minutes.