Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

<commit-configuration>

Usage

<rpc>
    <commit-configuration/>
    
    <commit-configuration>
        <check/>
    </commit-configuration>
    
    <commit-configuration>
        <log>log-message</log>
    </commit-configuration>
    
    <commit-configuration>
        <at-time>time-specification</at-time>
        <log>log-message</log>
    </commit-configuration>
    
    <commit-configuration>
        <confirmed/>
        <confirm-timeout>rollback-delay</confirm-timeout>
        <log>log-message</log>
    </commit-configuration>
    
    <commit-configuration>
        <synchronize/>
        <log>log-message</log>
    </commit-configuration>
    
    <commit-configuration>
        <synchronize/>
        <at-time>time-specification</at-time>
        <log>log-message</log>
    </commit-configuration>
    
    <commit-configuration>
        <synchronize/>
        <check/>
        <log>log-message</log>
    </commit-configuration>
    
    <commit-configuration>
        <synchronize/>
        <confirmed/>
        <confirm-timeout>rollback-delay</confirm-timeout>
        <log>log-message</log>
    </commit-configuration>

    <commit-configuration>
        <synchronize/>
        <force-synchronize/>
    </commit-configuration>
</rpc>

Release Information

This is a Junos XML management protocol operation. It is a Juniper Networks proprietary extension to NETCONF and is identified in the capabilities exchange by the URI http://xml.juniper.net/netconf/junos/1.0 . This operation is only supported in NETCONF sessions on Juniper Networks devices running the Junos OS.

Description

Request that the NETCONF server perform one of the variants of the commit operation on either the regular candidate configuration or a private copy of the candidate configuration (if the application emitted the <open-configuration><private/></open-configuration> tag sequence before making changes).

Some restrictions apply to the commit operation for a private copy. For example, the commit operation fails if the regular candidate configuration is locked by another user or application, or if it includes uncommitted changes made since the private copy was created. For more information, see the CLI User Guide.

• To commit the configuration immediately, making it the active configuration on the device, emit the empty <commit-configuration/> tag.
• To verify the syntactic correctness of the configuration without actually committing it, enclose the <check/> tag in the <commit-configuration> tag element.
• To record a message in the /var/log/commits file when the associated commit operation succeeds, define the log message string in the <log> tag element and enclose the tag element in the <commit-configuration> tag element. The <log> tag element can be combined with any other tag element. When the <log> tag element is emitted alone, the associated commit operation begins immediately.

• To commit the candidate configuration but roll back to the previous configuration after a short time, enclose the <confirmed/> tag in the <commit-configuration> tag element.

  By default, the rollback occurs after 10 minutes; to set a different rollback delay, also emit the optional <confirm-timeout> tag element. To delay the rollback again (past the original rollback deadline), emit the <confirmed/> tag (enclosed in the <commit-configuration> tag element) before the deadline passes. Include the <confirm-timeout> tag element to specify how long to delay the next rollback, or omit that tag element to use the default of 10 minutes. The rollback can be delayed repeatedly in this way.

  To commit the configuration immediately and permanently after emitting the <confirmed/> tag, emit the empty <commit-configuration/> tag before the rollback deadline passes. The NETCONF server commits the candidate configuration and cancels the rollback. If the candidate configuration is still the same as the current committed configuration, the effect is the same as recommitting the current committed configuration.

  Note: The confirmed commit operation is not available for a private copy of the configuration.

• On a device with two Routing Engines, commit the candidate configuration stored on the local Routing Engine on both Routing Engines. Combine tag elements as indicated in the following:
  • To copy the candidate configuration stored on the local Routing Engine to the other Routing Engine, verify the candidate’s syntactic correctness, and commit it immediately on both Routing Engines, enclose the <synchronize/> tag in the <commit-configuration> tag element.
  • To copy the candidate configuration stored on the local Routing Engine to the other Routing Engine, verify the candidate’s syntactic correctness, and commit it on both Routing Engines at a defined future time, enclose the <synchronize/> or <force-synchronize/> tag and <at-time> tag element in the <commit-configuration> tag element. Set the value in the <at-time> tag element as previously described for use of the <at-time> tag element alone.
  • To copy the candidate configuration stored on the local Routing Engine to the other Routing Engine and verify the candidate’s syntactic correctness on each Routing Engine, enclose the <synchronize/> or <force-synchronize/> and <check/> tag elements in the <commit-configuration> tag element.
  • To copy the candidate configuration stored on the local Routing Engine to the other Routing Engine, verify the candidate’s syntactic correctness, and commit it on both Routing Engines but require confirmation, enclose the <synchronize/> tag and <confirmed/> tag elements, and optionally the <confirm-timeout> tag element, in the <commit-configuration> tag element. Set the value in the <confirm-timeout> tag element as previously described for use of the <confirmed/> tag and <confirm-timeout> tag element alone.
  • To force the same synchronized commit operation as invoked by the <synchronize/> tag to succeed, even if there are open configuration sessions or uncommitted configuration changes on the remote machine, enclose the <force-synchronize/> tag in the <commit-configuration> tag element.

• To schedule the configuration for commit at a future time, enclose the <at-time> tag element in the <commit-configuration> tag element. There are three valid types of time specifiers:
  • The string reboot, to commit the configuration the next time the device reboots.
  • A time value of the form hh:mm[:ss] (hours, minutes, and, optionally, seconds), to commit the configuration at the specified time, which must be in the future but before 11:59:59 PM on the day the <commit-configuration> tag element is emitted. Use 24-hour time for the hh value; for example, 04:30:00 means 4:30:00 AM and 20:00 means 8:00 PM. The time is interpreted with respect to the clock and time zone settings on the device.
  • A date and time value of the form yyyy-mm-dd hh:mm[:ss] (year, month, date, hours, minutes, and, optionally, seconds), to commit the configuration at the specified date and time, which must be after the <commit-configuration> tag element is emitted. Use 24-hour time for the hh value. For example, 2005-08-21 15:30:00 means 3:30 PM on August 21, 2005. The time is interpreted with respect to the clock and time zone settings on the device.

    Note: The time you specify must be more than 1 minute later than the current time on the device.

    The configuration is checked immediately for syntactic correctness. If the check succeeds, the configuration is scheduled for commit at the specified time. If the check fails, the commit operation is not scheduled.

Usage Guidelines