 |
Note: You cannot perform this commit operation on a private copy of the configuration. |
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 <commit-configuration> and <rpc> tag elements:
<rpc>
<commit-configuration>
<confirmed/>
</commit-configuration>
</rpc>
If the commit is not confirmed within a certain amount of time (10 minutes by default), the JUNOScript server automatically retrieves and commits (rolls back to) the previously committed configuration. To specify a different number of minutes for the rollback deadline, the application encloses a positive integer value in the <confirm-timeout> tag element:
<rpc>
<commit-configuration>
<confirmed/>
<confirm-timeout>minutes</confirm-timeout>
</commit-configuration>
</rpc>
|
Note: You cannot perform this commit operation on a private copy of the configuration. |
The confirmed commit operation is useful for verifying that a configuration change works correctly and does not prevent management access to the routing platform. If the change prevents access or causes other errors, the automatic rollback to the previous configuration restores access after the rollback deadline passes.
In response to a confirmed commit operation, the JUNOScript server returns <rpc-reply>, <commit-results>, and <routing-engine> tag elements. If the commit operation succeeds, the <routing-engine> tag 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 routing platforms that use a single Routing Engine, and either re0 or re1 on routing platforms that can have two Routing Engines):
<rpc-reply xmlns:junos="URL">
<commit-results>
<routing-engine>
<name>(re0 | re1)</name>
<commit-success/>
</routing-engine>
</commit-results>
</rpc-reply>
If the commit operation fails, an <xnm:error> tag element encloses tag elements that describe the error. The most common causes of failure are semantic or syntactic errors in the candidate configuration.
To delay the rollback to a time later than the current rollback deadline, the application encloses the <confirmed/> tag in a <commit-configuration> tag element again before the deadline passes. It can include the <confirm-timeout> tag element to specify how long to delay the next rollback, or omit that tag element to delay the rollback by the default of 10 minutes. The application can delay the rollback indefinitely by emitting the <confirmed/> tag repeatedly in this way.
To cancel the rollback completely (and commit a configuration permanently), the application emits one of the following tag sequences before the rollback deadline passes:
<rpc>
<commit-configuration/>
</rpc>
<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. If a confirmed commit operation has been performed on both Routing Engines, then emitting the <synchronize/> tag cancels the rollback on both.
<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.
The <confirmed/> and <confirm-timeout> tag elements can be combined with the <synchronize/> tag, the <log/> tag element, or both. For more information, see Committing and Synchronizing a Configuration on Redundant Control Planes and Logging a Message About a Commit Operation.
The following example shows how to commit the candidate configuration on Routing Engine 1 with a rollback deadline of 20 minutes.
 | Copyright © 2009, Juniper Networks, Inc. All rights reserved. Trademark Notice. | |