When committing changes to a firewall, what is the result of clicking the preview changes link?

The commit configuration mode command enables you to save the device configuration changes to the configuration database and to activate the configuration on the device.

The device configuration is saved using a commit model—a candidate configuration is modified as desired and then committed to the system. When a configuration is committed, the device checks the configuration for syntax errors, and if no errors are found, the configuration is saved as juniper.conf.gz and activated. The formerly active configuration file is saved as the first rollback configuration file (juniper.conf.1.gz), and any other rollback configuration files are incremented by 1. For example, juniper.conf.1.gz is incremented to juniper.conf.2.gz, making it the second rollback configuration file. The device can have a maximum of 49 rollback configurations (numbered 1 through 49) saved on the system.

On the device, the current configuration file and the first three rollback files (juniper.conf.gz.1, juniper.conf.gz.2, juniper.conf.gz.3) are located in the /config directory. (The remaining rollback files, 4 through 49, are located in /var/db/config.)

If the recovery configuration file rescue.conf.gz exists, this file is also located in the /config directory. The factory default files are located in the /etc/config directory.

There are two mechanisms used to propagate the configurations between Routing Engines within a device:

• Synchronization: Propagates a configuration from one Routing Engine to a second Routing Engine within the same device chassis.

  To synchronize configurations, use the commit synchronize CLI command. If one of the Routing Engines is locked, the synchronization fails. If synchronization fails because of a locked configuration file, you can use the commit synchronize force command. This command overrides the lock and synchronizes the configuration files.

• Distribution: Propagates a configuration across the routing plane on a multichassis device. Distribution occurs automatically. There is no user command available to control the distribution process. If a configuration is locked during a distribution of a configuration, the locked configuration does not receive the distributed configuration file, so the synchronization fails. You need to clear the lock before the configuration and resynchronize the routing planes.

  Note:

  When you use the commit synchronize force CLI command on a multichassis platform, the forced synchronization of the configuration files does not affect the distribution of the configuration file across the routing plane. If a configuration file is locked on a device remote from the device where the command was issued, the synchronization fails on the remote device. You need to clear the lock and reissue the synchronization command.

To save device configuration changes to the configuration database and to activate the configuration on the device, use the commit configuration mode command. You can issue the commit command from any hierarchy level:

When you enter the commit command, the configuration is first checked for syntax errors (commit check). Then, if the syntax is correct, the configuration is activated and becomes the current, operational device configuration.

Note:

We do not recommend performing a commit operation on the backup Routing Engine when graceful Routing Engine switchover is enabled on the router.

A configuration commit can fail for any of the following reasons:

• The configuration includes incorrect syntax, which causes the commit check to fail.

• The candidate configuration that you are trying to commit is larger than 700 MB.

• The configuration is locked by a user who entered the configure exclusive command.

If the configuration contains syntax errors, a message indicates the location of the error, and the configuration is not activated. The error message has the following format:

For example:

You must correct the error before recommitting the configuration. To return quickly to the hierarchy level where the error is located, copy the path from the first line of the error and paste it at the configuration mode prompt at the [edit] hierarchy level.

The uncommitted, candidate configuration file is /var/rundb/juniper.db. It is limited to 700 MB. If the commit fails with a message configuration database size limit exceeded, view the file size from configuration mode by entering the command run file list /var/rundb detail. You can simplify the configuration and reduce the file size by creating configuration groups with wildcards or defining less specific match policies in your firewall filters.

Note:

CLI commit-time warnings displayed for configuration changes at the [edit interfaces] hierarchy level are removed and are logged as system log messages.

This is also applicable to VRRP configuration at the following hierarchy levels:

• [edit interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

• [edit logical-systems logical-system-name interfaces interface-name unit logical-unit-number family (inet | inet6) address address]

When you commit a configuration, you commit the entire configuration in its current form.

Note:

• We do not recommend performing a commit operation on the backup Routing Engine when graceful Routing Engine switchover is enabled on the device.

• If you configure the same IP address for a management interface or internal interface such as fxp0 and an external physical interface such as ge-0/0/1, when graceful Routing Engine switchover (GRES) is enabled, the CLI displays an appropriate commit error message that identical addresses have been found on the private and public interfaces. In such cases, you must assign unique IP addresses for the two interfaces that have duplicate addresses.

Up to 32 users can be in configuration mode simultaneously making changes to the configuration. All changes made by all users are visible to everyone editing the configuration—the changes become visible as soon as the user presses the Enter key at the end of a command that changes the configuration, such as set, edit, or delete.

When any of the users editing the configuration issues a commit command, the CLI checks and activates all changes by all users.

If you enter configuration mode with the configure private command, each user has a private candidate configuration to edit somewhat independently of other users. When you commit the configuration, the CLI commits only your own changes. To synchronize your copy of the configuration after other users have committed changes, you can run the update command in configuration mode. A commit operation also updates all the private candidate configurations. For example, suppose user X and user Y are both in configure private mode, and user X commits a configuration change. When user Y performs a subsequent commit operation and then views the new configuration, the new configuration seen by user Y includes the changes made by user X.

If you enter configuration mode with the configure exclusive command, you lock the candidate configuration for as long as you remain in configuration mode. This allows you to make changes without interference from other users. Other users can enter and exit configuration mode, but they cannot commit the configuration. This is true even if the other users entered configuration mode before you enter the configure exclusive command. For example, suppose user X is already in the configure private or configure mode. Then suppose user Y enters the configure exclusive mode. User X cannot commit any changes to the configuration, even if user X entered those changes before user Y logged in. If user Y exits configure exclusive mode, user X can then commit the changes made in configure private or configure mode.

You can complete the commit process in two steps. The two-step commit feature enables you to configure several devices and simultaneously activate the configurations. Two-step commit provides a definitive time window for the commit to be effective on the system. You can enter commit mode after the commit is prepared, but you will receive a message that the commit is pending activation.

In the first step, the preparation stage, the commit is validated and a new database with the necessary files is generated. If the configuration contains any syntax errors, an appropriate error message is displayed, and the configuration is not prepared. In the event of failure during the preparation stage, the error message commit check-out faileddisplays.

In the second step, the activation stage, the previously prepared configuration is activated. Next, if you need to clear the prepared configuration, you can do so by using clear system commit prepared command. A log message is generated upon successful clearing of the pending commit.

Note:

You cannot perform commit operations in between preparation and activation stages.

The two-step commit process is superior to the single-step process for time-critical commits. In the single-step process, the preparation time can vary depending on the existing configuration on the device. In the two-step process, the complex preparation work is more efficiently handled.

Configuration commands are provided that allow you to prepare the configuration cache and activate the configuration. You can prepare the devices with new configurations and activate them at the exact times you want.

The commit prepare command validates the configurations, and the commit activate command activates the configurations. The commands have the following configuration options:

• and-quit

• no-synchronize

• peers-synchronize

• synchronize

The commit prepare and commit activate commands are available for private, exclusive and shared commits only. The commands are not applicable for dynamic and ephemeral modes. This feature is applicable for multichassis devices, but it is not applicable for batch commits.

To support this functionality using Network Configuration Protocol (NETCONF), the following new remote procedure calls (RPCs) are provided:

• <commit-configuration>< prepare/></commit-configuration>

• <commit-configuration><activate/></commit-configuration>

• <clear-system-commit><prepared/></clear-system-commit>

Note:

• In an MX Series Virtual Chassis setup the following applies: When commit prepare is issued on one Routing Engine followed by switchover, the Routing Engine where the switchover command is issued reboots. Therefore, the prepared cache is cleared in that Routing Engine.

• In an MX Series Virtual Chassis setup, it is advisable to execute clear system commit prepared command only on VC primary.

You can complete the commit process in two steps. This enables you to configure several devices, and the configurations can be activated simultaneously. In the first step, known as the preparation stage, the commit is validated and a new database along with necessary files is generated. If the configuration contains any syntax errors, an appropriate error message is displayed, and the configuration is not prepared. In the second step, referred to as the activation stage, the previously prepared configuration is activated and becomes the current, operational device configuration.

To prepare the configuration:

1. At the [edit] hierarchy level in configuration mode, make the necessary changes to the configuration.
2. Issue the commit prepare command.
3. To verify the output of the show system commit command after commit prepare is issued, use the following command:

To activate the prepared configuration:

1. Use the commit activate command

   [edit] user@host# commit activate

   The message commit complete is displayed.

2. To verify the activated system configuration, use the following command:

   user@host> show configuration system scripts language python;

To verify the output of the show system commit and show system commit revision detail commands after commit activate is issued, issue the following commands.

When you commit the current candidate configuration, you can require an explicit confirmation for the commit to become permanent. This is useful if you want to verify that a configuration change works correctly and does not prevent access to the device. If the change prevents access or causes other errors, the device automatically returns to the previous configuration and restores access after the rollback confirmation timeout passes. This feature is called automatic rollback.

To commit the current candidate configuration but require an explicit confirmation for the commit to become permanent, use the commit confirmed configuration mode command:

Once you have verified that the change works correctly, you can keep the new configuration active by entering a commit or commit check command within 10 minutes of the commit confirmed command. For example:

If the commit is not confirmed within a certain time (10 minutes by default), the operating system automatically rolls back to the previous configuration and a broadcast message is sent to all logged-in users.

To show when a rollback is scheduled after a commit confirmed command, enter the show system commit command. For example:

Like the commit command, the commit confirmed command verifies the configuration syntax and reports any errors. If there are no errors, the configuration is activated temporarily (10 minutes by default) and begins running on the device.

Figure 1: Confirm a Configuration

To change the amount of time before you must confirm the new configuration, specify the number of minutes when you issue the command:

You can also use the commit confirmed command in the [edit private] configuration mode.

You can schedule when you want your candidate configuration to become active. To save device configuration changes and activate the configuration on the device at a future time or upon reboot, use the commit at configuration mode command, specifying reboot or a future time at the [edit] hierarchy level:

string is reboot or the future time to activate the configuration changes. 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 mode 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, 2018-08-21 12:30:00 is 12:30 PM on August 21, 2018. The time is interpreted with respect to the clock and time zone settings on the router.

Enclose the string value in quotation marks (" "). 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 "2018-03-10 14:00:00".

A commit check is performed immediately 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 the device software fails before the configuration changes become active, all configuration changes are lost.

You cannot enter the commit at configuration command after you issue the request system reboot command.

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 cancel a scheduled configuration by means of the clear command, see the CLI Explorer.

Note:

We do not recommend performing a commit operation on the backup Routing Engine when graceful Routing Engine switchover is enabled on the device.

To monitor the device configuration commit process, use the display detail command after the pipe with the commit command:

For example:

Batch commit aggregates or merges multiple configuration edits from different CLI sessions or users and adds them to a batch commit queue. A batch commit server running on the device takes one or more jobs from the batch commit queue, applies the configuration changes to the shared configuration database, and then commits the configuration changes in a single commit operation.

Batches are prioritized by the commit server based on priority of the batch specified by the user or the time when the batch job is added. When one batch commit is complete, the next set of configuration changes are aggregated and loaded into the batch queue for the next session of the batch commit operation. Batches are created until there are no commit entries left in the queue directory.

When compared to the regular commit operation where all commits are independently committed sequentially, batch commits save time and system resources by committing multiple small configuration edits in a single commit operation.

Batch commits are performed from the [edit batch] configuration mode. The commit server properties can be configured at the [edit system commit server] hierarchy level.

When there is a load-time error in one of the aggregated jobs, the commit job that encounters the error is discarded and the remaining jobs are aggregated and committed.

For example, if there are five commit jobs (commit-1, commit-2, commit-3, commit-4, and commit-5) being aggregated, and commit-3 encounters an error while loading, commit-3 is discarded and commit-1, commit-2, commit-4, and commit-5 are aggregated and committed.

If there is an error during the commit operation when two or more jobs are aggregated and committed, the aggregation is discarded and each of those jobs is committed individually like a regular commit operation.

For example, if there are five commit jobs (commit-1, commit-2, commit-3, commit-4, and commit-5) that are aggregated and if there is a commit error caused because of commit-3, the aggregation is discarded, commit-1, commit-2, commit-3, commit-4, and commit-5 are committed individually, and the CLI reports a commit error for commit-3.

This example shows how to configure batch commit server properties to manage batch commit operations.

• Requirements
• Overview
• Configuration
• Verification

This example uses the following hardware and software components:

• MX Series 5G Universal Routing Platform

You can control how the batch commit queue is handled by the commit server by configuring the server properties at the [edit system commit server] hierarchy level. This enables you to control how many commit jobs are aggregated or merged into a single batch commit, the maximum number of jobs that can be added to the queue, days to keep batch commit error logs, interval between two batch commits, and tracing operations for batch commit operations.

To quickly configure this section of the example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level. You can configure the commit server properties from either the regular [edit] mode or the [edit batch] mode.

Device R0

• Step-by-Step Procedure
• Results

Confirm that the configuration is working properly.

After you commit the configuration and are satisfied that it is running successfully, you should issue the request system snapshot command to back up the new software onto the /altconfig file system. If you do not issue the request system snapshot command, the configuration on the alternate boot drive is out of sync with the configuration on the primary boot drive.

The request system snapshot command backs up the root file system to /altroot, and /config to /altconfig. The root and /config file systems are on the router’s flash drive, and the /altroot and /altconfig file systems are on the router’s hard disk (if available).

After you issue the request system snapshot command, you cannot return to the previous version of the software because the running and backup copies of the software are identical.