Commit and Synchronize Ephemeral Configuration Data Using the NETCONF or Junos XML Protocol

The ephemeral database is an alternate configuration database that enables NETCONF and Junos XML protocol client applications to simultaneously load and commit configuration changes on Junos devices and with significantly greater throughput than when committing data to the candidate configuration database. Client applications can commit the configuration data in an open instance of the ephemeral configuration database so that it becomes part of the active configuration on the device. When you commit ephemeral configuration data on a device, the device’s active configuration is a merged view of the static and ephemeral configuration databases.

After a client application commits an ephemeral instance, the device merges the configuration data into the ephemeral database. The affected system processes parse the configuration and merge the ephemeral data with the data in the active configuration. If there are conflicting statements in the static and ephemeral configuration databases, the data is merged according to specific rules of prioritization. The database priority, from highest to lowest, is as follows:

1. Statements in a user-defined instance of the ephemeral configuration database.

   If there are multiple user-defined ephemeral instances, the priority is determined by the order in which the instances are configured at the [edit system configuration-database ephemeral] hierarchy level, running from highest to lowest priority.

2. Statements in the default ephemeral database instance.

3. Statements in the static configuration database.

The active device configuration is a merged view of the static and ephemeral configuration databases. However, when you display the configuration in the CLI using the show configuration operational mode command, the output does not include ephemeral configuration data. In the CLI, you can display the data in a specific instance of the ephemeral database or display a merged view of the static and ephemeral configuration databases by using variations of the show ephemeral-configuration command.

Client applications can commit the configuration data in an open instance of the ephemeral configuration database so that it becomes part of the active configuration on the device. To commit the configuration, use the <commit-configuration/> operation in a Junos XML protocol session or the <commit-configuration/> or <commit/> operation in a NETCONF session.

In a Junos XML protocol session, a client application commits the configuration data in an open instance of the ephemeral configuration database by enclosing the <commit-configuration/> tag in an <rpc> tag element (just as for the candidate configuration).

The Junos XML protocol server reports the results of the commit operation in <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 specifies the target Routing Engine.

In a NETCONF session, a client application commits the configuration data in an open instance of the ephemeral configuration database by enclosing the <commit/> or <commit-configuration/> tag in an <rpc> tag element (just as for the candidate configuration).

The NETCONF server confirms that the commit operation was successful by returning the <ok/> tag in an <rpc-reply> tag element.

If the commit operation fails, the NETCONF server returns the <rpc-reply> element and <rpc-error> child element, which explains the reason for the failure.

The only variant of the commit operation supported for the ephemeral database is synchronizing the configuration, as described in Synchronizing an Ephemeral Instance Overview.

Dual Routing Engine devices and Virtual Chassis systems do not automatically synchronize ephemeral configuration data when you issue a commit operation on an ephemeral instance. You can synchronize the data in an ephemeral instance on a per-commit or per-session basis, or you can configure an ephemeral instance to synchronize its data every time you commit the instance. The environment determines where the data is synchronized, for example:

• On devices with dual Routing Engines, the device synchronizes the ephemeral instance to the backup Routing Engine.

• An MX Series Virtual Chassis synchronizes the ephemeral instance only to the backup device's primary Routing Engine.

• An EX Series Virtual Chassis synchronizes the ephemeral instance to all members switches.

See the following sections for instructions on synchronizing ephemeral instances:

• How to Configure GRES-Enabled Devices to Synchronize Ephemeral Configuration Data

• How to Synchronize an Ephemeral Instance on a Per-Commit Basis

• How to Synchronize an Ephemeral Instance on a Per-Session Basis

• How to Automatically Synchronize an Ephemeral Instance Upon Commit

• How to Configure Failover Configuration Synchronization for the Ephemeral Database

By default, the ephemeral commit model executes commit synchronize operations asynchronously. The NETCONF or Junos XML protocol server commits the configuration on the local Routing Engine and then commits the configuration on the remote Routing Engine or Virtual Chassis members. The requesting Routing Engine commits the ephemeral configuration and emits a commit complete notification without waiting for the other Routing Engine or Virtual Chassis members to first synchronize and commit the configuration.

On supported devices, you can also configure the ephemeral database to use a synchronous commit model for commit synchronize operations. Synchronous commit operations are slower but more reliable than asynchronous commit operations. To use the synchronous model, configure the commit-synchronize-model synchronous statement at the [edit system configuration-database ephemeral] hierarchy level in the static configuration database.

When you synchronize an ephemeral instance, the Junos XML protocol server reports the results of the commit operation for the local Routing Engine in <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 specifies the target Routing Engine.

The server reply includes additional tags that depend on the commit synchronize model used by the database.

• If the ephemeral database uses the synchronous model, the server reply includes a second <routing-engine> element for the commit operation on the other Routing Engine.

• If the ephemeral database uses the asynchronous model, the server includes the <commit-synchronize-server-success> tag element, which indicates that the synchronize operation is scheduled on the other Routing Engine or Virtual Chassis members and provides the estimated time in seconds required for the operation to complete.

For example:

The RPC reply for synchronous commit synchronize operations indicates the success or failure of the commit operation on the other Routing Engine or Virtual Chassis members. The device records the success or failure of asynchronous commit synchronize operations in the system log file, provided the device is configured to log events of the given facility and severity level. See the System Log Explorer for the various ephemeral database events and the facility and severity levels required to log them.

Similarly, in NETCONF sessions, the server confirms that the commit operation was successful by returning the <ok/> tag in an <rpc-reply> tag element. Depending on the device configuration, the response may also include the <commit-results> element for synchronous commit synchronize operations or the <commit-synchronize-server-success> element for asynchronous commit synchronize operations. For example:

By default, the ephemeral database performs commit synchronize operations asynchronously and does not synchronize ephemeral configuration data to the backup Routing Engine or other Virtual Chassis members when you enable graceful Routing Engine switchover (GRES). If the ephemeral database uses the asynchronous commit synchronize model, you must configure the allow-commit-synchronize-with-gres statement to allow GRES-enabled devices to perform commit synchronize operations.

Alternatively, on supported devices, you can instead configure the ephemeral database to use a synchronous commit model to perform commit synchronize operations. Synchronous commit operations are slower but more reliable than asynchronous commit operations. We recommend that you use the synchronous commit model on devices that have GRES enabled.

To enable devices that have GRES configured to synchronize ephemeral configuration data:

You can synchronize an ephemeral instance across Routing Engines or Virtual Chassis members for a given commit operation on that instance.

To synchronize an ephemeral instance on a per-commit basis:

You can synchronize an ephemeral instance across Routing Engines or Virtual Chassis members for all commit operations performed for the duration that the ephemeral instance is open, which we are loosely referring to as a session. This should not be confused with the NETCONF or Junos XML protocol session. Synchronizing the instance on a per-session basis enables you to execute multiple load and commit operations and ensure that each commit operation automatically synchronizes the instance until you close it.

To synchronize an ephemeral instance for all commit operations performed for the duration that the instance is open:

On devices running Junos OS Release 22.1R1 or later and devices running Junos OS Evolved, you can configure an ephemeral instance so that it synchronizes its configuration across Routing Engines or Virtual Chassis members every time you commit the instance.

To configure the ephemeral instance to synchronize every time you commit the instance:

MX Series Virtual Chassis and dual Routing Engine devices support failover configuration synchronization for the ephemeral database, which helps ensure that the configuration database is synchronized between Routing Engines in the event of a Routing Engine switchover. This is achieved when you configure the commit synchronize statement at the [edit system] hierarchy level in the static configuration database.

If you configure the commit synchronize statement in the static configuration database, it has the following effects:

• The device synchronizes its static configuration database to the other Routing Engine during a commit operation.

• Starting in Junos OS Release 20.2R1, the backup Routing Engine synchronizes both the static and ephemeral configuration databases when it synchronizes with the primary Routing Engine. In earlier releases, the backup Routing Engine only synchronizes the static configuration database.

When you configure the commit synchronize statement on the primary and backup Routing Engines, the backup Routing Engine synchronizes its configuration with the primary Routing Engine in the following scenarios:

• The backup Routing Engine is removed and reinserted

• The backup Routing Engine is rebooted

• The device performs a graceful Routing Engine switchover

• There is a manual change in roles

• A new backup Routing Engine is inserted that has the commit synchronize statement configured

On a dual Routing Engine system, the backup Routing Engine synchronizes its configuration databases with the primary Routing Engine. In an MX Series Virtual Chassis, the primary Routing Engine on the backup device synchronizes its configuration databases with the primary Routing Engine on the primary device.

To enable failover configuration synchronization for both the static and ephemeral databases on supported devices running Junos OS Release 20.2R1 or later or devices running Junos OS Evolved: