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

The ephemeral database is an alternate configuration database. It 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 system processes parse the configuration and then merge the ephemeral data with the data in the active configuration. If there are conflicting statements in the static and ephemeral configuration databases, the device merges the data 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 the device uses multiple user-defined ephemeral instances, it determines the priority 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 using the show configuration command in operational mode, the output does not include ephemeral configuration data. To display the data in a specific ephemeral database instance or display a merged view of the static and ephemeral configuration databases, use variations of the show ephemeral-configuration CLI 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 performing a <commit-configuration/> operation (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> element encloses the <commit-success/> tag and the <name> 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 performing a <commit/> or <commit-configuration/> operation (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 Overview of Synchronizing an Ephemeral Instance.

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

• A dual Routing Engine 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

The ephemeral database supports two commit synchronize models: asynchronous and synchronous. Starting in Junos OS Release 25.4R1 and Junos OS Evolved Release 25.4R1, the ephemeral database uses the synchronous model by default. In earlier releases, the asynchronous model is the default. You can configure the commit-synchronize-model statement to explicitly configure the model.

In the asynchronous commit model, the NETCONF or Junos XML protocol server first commits the configuration on the local Routing Engine and then notifies the other Routing Engine or Virtual Chassis device. The requesting Routing Engine does not wait for the other Routing Engine or Virtual Chassis member to first synchronize and commit the configuration.

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 graceful Routing Engine switchover (GRES) or nonstop active routing (NSR) enabled. In the synchronous model, the primary Routing Engine or MX Virtual Chassis primary device generally only completes its commit operation if the commit on the backup Routing Engine or Virtual Chassis backup device is successful.

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> element encloses the <commit-success/> tag and the <name> 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> element. This tag 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:

For synchronous commit operations, the RPC reply indicates the success or failure of the commit operation on the other Routing Engine or Virtual Chassis members. For asynchronous commit operations, the device records the success or failure of the scheduled commit operations in the system log file. You must configure the device to log events of the given facility and severity level corresponding to these operations. 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 might 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:

The ephemeral database supports two commit synchronize models: asynchronous and synchronous. To ensure a GRES-enabled device synchronizes ephemeral configuration data when you request a commit synchronize operation on an ephemeral instance, you must use one of the following methods:

• Use the synchronous model

• Use the asynchronous model and configure the allow-commit-synchronize-with-gres statement

We recommend that you use the synchronous model on devices that enable GRES. Additionally, starting in Junos OS Release 25.4R1 and Junos OS Evolved Release 25.4R1, the ephemeral database uses the synchronous model by default and devices that enable GRES must use the synchronous model. In earlier releases, the asynchronous model supports synchronizing ephemeral data on GRES-enabled devices provided that you configure the allow-commit-synchronize-with-gres statement. However, we do not recommend using the asynchronous model on devices that enable GRES.

To configure GRES-enabled devices 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 session 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:

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

When 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 backup Routing Engine or MX Virtual Chassis backup device during a commit operation.

  Note:

  If you configure the commit synchronize statement in the static configuration database, the device does not automatically synchronize an ephemeral instance to the backup device when you commit the static configuration database or when you commit the instance.

• Starting in Junos OS Release 20.2R1, a backup Routing Engine or an MX Virtual Chassis backup device synchronizes both its static and ephemeral configuration databases when it synchronizes with the primary device. In earlier releases, a backup Routing Engine only synchronizes the static configuration database.

  Note:

  For failover synchronization, the backup Routing Engine and the MX Virtual Chassis backup device only synchronize the ephemeral configuration database with the primary device if both the backup device and the primary device are running the same software version.

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:

• You remove and reinsert the backup Routing Engine

• You reboot the backup Routing Engine

• The device performs a graceful Routing Engine switchover

• There is a manual change in roles

• You insert a new backup Routing Engine 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: