Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Committing and Synchronizing Ephemeral Configuration Data Using the NETCONF or Junos XML Protocol

Committing an Ephemeral Instance Overview

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 devices running Junos OS 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 routing, switching, or security platform. When you commit ephemeral configuration data on a device running Junos OS, the device’ s active configuration is a merged view of the static and ephemeral configuration databases.

CAUTION:

In the ephemeral commit model, Junos OS validates the syntax but not the semantics, or constraints, of the configuration data committed to the ephemeral database. You must validate all configuration data before loading it into the ephemeral database and committing it on the device, because committing invalid configuration data can cause Junos OS processes to restart or even crash and result in disruption to the system or network.

After a client application commits an ephemeral instance, the data in that instance is merged into the ephemeral configuration 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.

Note:

Although applications can simultaneously load and commit data to different instances of the ephemeral database, commits issued at the same time from different ephemeral instances are queued and processed serially by the device.

Note:

If you commit ephemeral configuration data that is invalid or results in undesirable network disruption, you must delete the problematic data from the database, or if necessary, reboot the device, which deletes the configuration data in all instances of the ephemeral 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 command in operational mode, the output does not include ephemeral configuration data. 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 in the CLI by using variations of the show ephemeral-configuration command.

How to Commit an Ephemeral Instance

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 routing, switching, or security platform by using 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 with a device running Junos OS, 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 reports the name of the Routing Engine on which the commit operation succeeded.

In a NETCONF session with a device running Junos OS, 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 on the other Routing Engine, as described in Synchronizing an Ephemeral Instance Overview.

Synchronizing an Ephemeral Instance Overview

Devices running Junos OS do not automatically synchronize ephemeral configuration data to a backup Routing Engine when you issue a commit operation on an ephemeral instance in a dual Routing Engine system or MX Series Virtual Chassis. You can synchronize the data in an ephemeral instance on a per-commit or per-session basis. On devices with dual Routing Engines, the device synchronizes the ephemeral instance to the backup Routing Engine. In MX Series Virtual Chassis configurations, the system synchronizes the ephemeral instance only to the backup device's primary Routing Engine.

Note:

Multichassis environments do not support synchronizing the ephemeral configuration database to the other Routing Engines.

See the following sections for instructions on synchronizing ephemeral instances:

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 copies the configuration to the remote Routing Engine and commits it. The requesting Routing Engine commits the ephemeral configuration and emits a commit complete notification without waiting for the other Routing Engine to first synchronize and commit the configuration.

On supported devices running Junos OS Release 21.1R1 or later, you can also configure the ephemeral database to execute commit synchronize operations using a synchronous commit model. In this model, the primary Routing Engine only completes its commit operation if the commit on the other Routing Engine is successful. 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 reports the name of the Routing Engine on which the commit operation succeeded.

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 for commit synchronize operations, 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 for commit synchronize operations, the server includes the <commit-synchronize-server-success> tag element, which indicates that the synchronize operation is scheduled on the other Routing Engine 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. Junos OS 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. The response also includes the <commit-results> element for synchronous commit synchronize operations or the <commit-synchronize-server-success> element for asynchronous commit synchronize operations.

Note:

The device does not synchronize the ephemeral configuration database to the other Routing Engine when you issue the commit synchronize command on the static configuration database.

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

By default, the ephemeral database performs commit synchronize operations asynchronously and does not synchronize ephemeral configuration data to the backup Routing Engine on devices that have graceful Routing Engine switchover (GRES) enabled. 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 running Junos OS Release 21.1R1 or later, 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 using the synchronous commit model on devices that have GRES enabled.

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

  1. (Optional) Configure the commit model that the ephemeral database uses to perform commit synchronize operations.
  2. If the device uses the asynchronous commit model, which is the default, configure the allow-commit-synchronize-with-gres statement in the static configuration database.
  3. Commit the configuration.

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

You can synchronize an ephemeral instance to the other Routing Engine for each commit operation on the instance.

To synchronize an ephemeral instance to the other Routing Engine on a per-commit basis:

  1. Open the ephemeral instance.
  2. Configure the ephemeral instance.
  3. Commit and synchronize the instance by enclosing the empty <synchronize/> tag in the <commit-configuration> and <rpc> tag elements.
  4. Repeat steps 2 and 3, as appropriate.
  5. Close the ephemeral instance.

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

You can synchronize an ephemeral instance to the other Routing Engine 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 to the other Routing Engine until the instance is closed.

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

  1. Open the ephemeral instance, and include the <commit-synchronize/> tag.
  2. Configure the ephemeral instance.
  3. Commit the instance, which also synchronizes it to the other Routing Engine.
  4. Repeat steps 2 and 3, as appropriate.
  5. Close the ephemeral instance.

How to Configure Failover Configuration Synchronization for the Ephemeral Database

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.

Note:

Configuring the commit synchronize statement in the static configuration database does not synchronize an ephemeral instance to the backup Routing Engine when you commit the static configuration database or when you commit the instance.

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 devices running Junos OS Release 20.2R1 or later:

  1. Configure the synchronize statement in the static configuration database.
  2. Commit the configuration.