Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All
     

    Related Documentation

     

    commit

    Syntax

    commit <<at <"string">> <and-quit> <check> <comment <"comment-string">><confirmed> <display detail> <fast-synchronize> <minutes> <peers-synchronize > <synchronize <force> <scripts>>

    Release Information

    Command introduced before Junos OS Release 7.4.

    Command introduced in Junos OS Release 11.1 for the QFX Series.

    Option fast-synchronize added in Junos OS Release 12.2.

    Option synchronize scripts introduced in Junos OS Release 13.2.

    Command introduced in Junos OS Release 14.1X53-D20 for the OCX Series.

    Option peers-synchronize introduced in Junos OS Release 14.2R6.

    Option no-synchronize introduced in Junos OS Release 17.2R1

    Description

    Commit the set of changes to the database and cause the changes to take operational effect.

    Note: The fast-synchronize option is not supported in a QFX Series Virtual Chassis.

    Note: Beginning in Junos OS 12.3, it is possible that FPCs brought offline using the request chassis fpc slot fpc-slot offline operational-mode CLI command can come online during a configuration commit or power-supply replacement procedure. As an alternative, use the set fpc fpc-slot power off configuration-mode command at the [edit chassis] hierarchy level to ensure that the FPCs remain offline.

    Options

    at <"string">—(Optional) Save software configuration changes and activate the configuration at a future time, or upon reboot.

    string is reboot or the future time to activate the configuration changes. Enclose the string value (including reboot) in quotation marks (“ ”). You can specify time in two formats:

    • A time value in the form hh:mm[:ss] (hours, minutes, and optionally seconds)— Commit the configuration at the specified time, which must be in the future but before 11:59:59 PM on the day the commit at configuration command is issued. Use 24-hour time for the hh value; for example, 04:30:00 is 4:30:00 AM, and 20:00 is 8:00 PM. The time is interpreted with respect to the clock and time zone settings on the router.
    • A date and time value in the form yyyy-mm-dd hh:mm[:ss] (year, month, date, hours, minutes, and, optionally, seconds)—Commit the configuration at the specified day and time, which must be after the commit at command is issued. Use 24-hour time for the hh value. For example, 2003-08-21 12:30:00 is 12:30 PM on August 21, 2003. The time is interpreted with respect to the clock and time zone settings on the router.

    For example, commit at “18:00:00". For date and time, include both values in the same set of quotation marks. For example, commit at "2005-03-10 14:00:00".

    A commit check is performed when you issue the commit at configuration mode command. If the result of the check is successful, then the current user is logged out of configuration mode, and the configuration data is left in a read-only state. No other commit can be performed until the scheduled commit is completed.

    Note: If Junos OS fails before the configuration changes become active, all configuration changes are lost.

    You cannot enter the commit at configuration command when there is a pending reboot.

    You cannot enter the request system reboot command once you schedule a commit operation for a specific time in the future.

    You cannot commit a configuration when a scheduled commit is pending. For information about how to use the clear command to cancel a scheduled configuration, see the CLI Explorer.

    and-quit—(Optional) Commit the configuration and, if the configuration contains no errors and the commit succeeds, exit from configuration mode.

    check—(Optional) Verify the syntax of the configuration, but do not activate it.

    comment <"comment-string">—(Optional) Add a comment that describes the committed configuration. The comment can be as long as 512 bytes and must be typed on a single line. You cannot include a comment with the commit check command. Enclose comment-string in quotation marks (" "). For example, commit comment "Includes changes recommended by SW Lab".

    confirmed <minutes>—(Optional) Require that the commit be confirmed within the specified amount of time. To confirm a commit, enter either a commit or commit check command. If the commit is not confirmed within the time limit, the configuration rolls back automatically to the precommit configuration and a broadcast message is sent to all logged-in users. To show when a rollback is scheduled, enter the show system commit command. The allowed range is 1 through 65,535 minutes, and the default is 10 minutes.

    In Junos OS Release 11.4 and later, you can also use the commit confirmed command in the [edit private] configuration mode.

    display detail—(Optional) Monitors the commit process.

    Note: In Junos OS Release 10.4 and later, if the number of commit details or messages exceeds a page when used with the | display detail pipe option, the more pagination option on the screen is no longer available. Instead, the messages roll up on the screen by default, just like using the commit command with the | no more pipe option.

    fast-synchronize—(Optional) Configure the commits to run in parallel on both the master and backup Routing Engines to reduce the time taken for commit synchronization.

    Note: The fast-synchronize statement is not supported on QFX Series devices when used in a Virtual Chassis.

    peers-synchronize—(Optional) Automatically synchronizes and commits MC-LAG configurations across the peers. The local peer (the requesting peer) on which you enable the peers-synchronize statement copies and loads its configuration to the remote (the responding) peer. Each peer then performs a syntax check on the configuration file being committed. If no errors are found, the configuration is activated and becomes the current operational configuration on both peers.

    synchronize <force> <scripts>—(Optional) If your router has two Routing Engines, you can manually direct one Routing Engine to synchronize its configuration with the other by issuing the commit synchronize command. The Routing Engine on which you execute this command (the request Routing Engine) copies and loads its candidate configuration to the other Routing Engine (the responding Routing Engine). Both Routing Engines then perform a syntax check on the candidate configuration file being committed. If no errors are found, the configuration is activated and becomes the current operational configuration on both Routing Engines.

    It can happen that the commit synchronize command is initiated at the same time from both Routing Engines, which causes the process to hang. As of Junos OS Release 15.1, this is a temporary (20 seconds) anomaly, after which the user can try the commit sychronize command again.

    The commit synchronize command does not work if the responding Routing Engine has uncommitted configuration changes. However, you can enforce commit synchronization on the Routing Engines by using the force option. When you issue the commit synchronize command with the force option from one Routing Engine, the configuration sessions on the other Routing Engine are terminated and its configuration synchronized with that on the Routing Engine from which you issued the command.

    When you issue the commit synchronize command with the scripts option, the device synchronizes all commit, event, lib, op, and SNMP scripts from the requesting Routing Engine to the responding Routing Engine and also commits and synchronizes the configuration. If the commit check operation fails for the requesting Routing Engine, the process stops, and the scripts are not copied to the responding Routing Engine. If the commit check or commit operation fails for the responding Routing Engine, the scripts are still synchronized, since the synchronization occurs prior to the commit check operation on the responding Routing Engine.

    If the load-scripts-from-flash statement is configured for the requesting Routing Engine, the device synchronizes the scripts from flash memory on the requesting Routing Engine to flash memory on the responding Routing Engine. Otherwise, the device synchronizes the scripts from the hard disk on the requesting Routing Engine to the hard disk on the responding Routing Engine. The device synchronizes all scripts regardless of whether they are enabled in the configuration or have been updated since the last synchronization.

    Note: When you issue the commit synchronize command, you must use the apply-groups re0 and re1 commands. For information about how to use groups, see Disabling Inheritance of a Junos OS Configuration Group.

    The responding Routing Engine must use Junos OS Release 5.0 or later.

    no-synchronize—(Optional) Configure the commit command to run without synchronization. This can be useful in situations, for example, where a Routine Engine configuration is corrupted such that a commit synchronization is not possible or will block the commit. This option allows you to commit only on the current Routing Engine even if system commit synchronize is configured. This option overrides the commit peer-synchronize configuration as well. If you have configured the commit synchronize using set system commit synchronize and then use the command commit no-synchronize, the commit will happen only on the device issuing the command. When using commit synchronize, the commit is first done in the other Routing Engine and then in the current one. If the other Routine Engine is not in a sane state, the commit will fail. In such cases, you can use commit no-synchronize. This command cannot be configured using set. It can only be run.

    Required Privilege Level

    configure—To enter configuration mode.

    Note: If you are using Junos OS in a Common Criteria environment, system log messages are created whenever a secret attribute is changed (for example, password changes or changes to the RADIUS shared secret). These changes are logged during the following configuration load operations:

    load merge
    load replace
    load override
    load update
    

    For more information, see the Secure Configuration Guide for Common Criteria and Junos-FIPS

     

    Related Documentation

     

    Sample Output

    commit | display detail

    user@host> commit | display detail
    --------------
    2011-08-24 01:08:08.00691 PDT: begin creating snapshots
    2011-08-24 01:08:09.00210 PDT: end creating snapshots
    2011-08-24 01:08:09.00211 PDT: begin preparing metadata
    2011-08-24 01:08:09.00228 PDT: end preparing metadata
    2011-08-24 01:08:09.00229 PDT: begin computing dcf root changes
    2011-08-24 01:08:09.00236 PDT: end computing dcf root changes
    2011-08-24 01:08:09.00244 PDT: begin computing additions
    2011-08-24 01:08:09.00251 PDT: end computing additions
    2011-08-24 01:08:09.00251 PDT: begin local object validation
    2011-08-24 01:08:09.00251 PDT: end local object validation
    2011-08-24 01:08:09.00252 PDT: begin update instances
    2011-08-24 01:08:09.00252 PDT: end update instances
    2011-08-24 01:08:09.00252 PDT: begin adjust metadata
    2011-08-24 01:08:09.00252 PDT: end adjust metadata
    2011-08-24 01:08:09.00253 PDT: begin validate metadata
    2011-08-24 01:08:09.00253 PDT: end validate metadata
    2011-08-24 01:08:09.00253 PDT: begin adjust allocations
    2011-08-24 01:08:09.00254 PDT: end adjust allocations
    2011-08-24 01:08:09.00254 PDT: begin adjust dependencies
    2011-08-24 01:08:09.00254 PDT: end adjust dependencies
    2011-08-24 01:08:09.00255 PDT: begin instance validation
    2011-08-24 01:08:09.00255 PDT: end instance validation
    2011-08-24 01:08:09.00255 PDT: begin opening all sessions eagerly
    2011-08-24 01:08:09.00277 PDT: begin request #1 [login]
    2011-08-24 01:08:09.00278 PDT: end request #1 [login]
    2011-08-24 01:08:09.00325 PDT: begin processing globals
    2011-08-24 01:08:09.00330 PDT: begin waiting for stamp check (qfabric-default---node0)
    2011-08-24 01:08:09.00334 PDT: end reply #1 [login]
    2011-08-24 01:08:09.00351 PDT: end reply #1 [login]
    2011-08-24 01:08:09.00451 PDT: begin request #2 [open]
    2011-08-24 01:08:09.00451 PDT: end request #2 [open]
    2011-08-24 01:08:09.00451 PDT: begin request #3 [get commit history]
    2011-08-24 01:08:09.00452 PDT: end request #3 [get commit history]
    2011-08-24 01:08:09.00452 PDT: begin request #4 [load]
    2011-08-24 01:08:09.00453 PDT: end request #4 [load]
    2011-08-24 01:08:09.00453 PDT: begin request #5 [load]
    2011-08-24 01:08:09.00454 PDT: begin reply #2 [open]
    2011-08-24 01:08:09.00456 PDT: end reply #2 [open]
    2011-08-24 01:08:09.00457 PDT: begin reply #3 [get commit history]
    2011-08-24 01:08:09.00475 PDT: end reply #3 [get commit history]
    2011-08-24 01:08:09.00476 PDT: begin reply #4 [load]
    2011-08-24 01:08:09.00499 PDT: begin reply #5 [load]
    2011-08-24 01:08:09.00501 PDT: end waiting for stamp check (qfabric-default---node0)
    2011-08-24 01:08:09.00501 PDT: begin waiting for open (qfabric-default---node0)
    2011-08-24 01:08:09.00502 PDT: end waiting for open (qfabric-default---node0)
    2011-08-24 01:08:09.00504 PDT: end processing globals
    2011-08-24 01:08:09.00617 PDT: end request #5 [load]
    2011-08-24 01:08:09.00617 PDT: begin request #6 [check]
    2011-08-24 01:08:09.00617 PDT: end request #6 [check]
    2011-08-24 01:08:09.00619 PDT: end reply #5 [load]
    2011-08-24 01:08:09.00619 PDT: begin reply #6 [check]
    2011-08-24 01:08:09.00730 PDT: end session
    2011-08-24 01:08:09.00752 PDT: end request #5 [load]
    2011-08-24 01:08:09.00754 PDT: begin request #6 [check]
    2011-08-24 01:08:09.00755 PDT: end request #6 [check]
    2011-08-24 01:08:09.00881 PDT: end request #5 [load]
    2011-08-24 01:08:09.00961 PDT: begin commit to devices
    2011-08-24 01:08:10.00668 PDT: begin request #8 [get commit history]
    2011-08-24 01:08:10.00669 PDT: end request #8 [get commit history]
    2011-08-24 01:08:10.00721 PDT: end session
    2011-08-24 01:08:10.00727 PDT: end commit to devices
    2011-08-24 01:08:10.00733 PDT: begin committing metadata
    2011-08-24 01:08:10.00772 PDT: end committing metadata
    2011-08-24 01:08:10.00772 PDT: begin calling commit callbacks
    2011-08-24 01:08:10.00773 PDT: end calling commit callbacks
    commit complete
    

    Modified: 2017-05-04