Commit 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.
<rpc>
<commit-configuration>
<confirmed/>
</commit-configuration>
</rpc>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.
<rpc>
<commit-configuration>
<confirmed/>
<confirm-timeout>rollback-delay</confirm-timeout>
</commit-configuration>
</rpc>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).
<rpc-reply xmlns:junos="URL">
<commit-results>
<output>commit confirmed will be automatically rolled back in 10 minutes unless confirmed</output>
<routing-engine>
<name>(re0 | re1)</name>
<commit-success/>
</routing-engine>
</commit-results>
</rpc-reply>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.<rpc> <commit-configuration/> <check/> </commit-configuration/> </rpc>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:
<rpc> <commit-configuration/> </rpc>The
<synchronize/>tag enclosed in<commit-configuration>and<rpc>tag elements.<rpc> <commit-configuration> <synchronize/> </commit-configuration> </rpc>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.<rpc> <commit-configuration> <at-time>time</at-time> </commit-configuration> </rpc>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.
