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. Statements in a user-defined instance of the ephemeral configuration database have higher priority than statements in the default ephemeral database instance, which have higher priority than statements in the static 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.

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 the other Routing Engine when you issue a commit synchronize 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. If graceful Routing Engine switchover (GRES) is configured on the device, you must configure the allow-commit-synchronize-with-gres statement at the [edit system configuration-database ephemeral] hierarchy level in the static configuration database to enable the device to synchronize an ephemeral instance to the other Routing Engine when you request a commit synchronize operation on the instance.

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:

Unlike the standard commit model, the ephemeral commit model performs 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 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 master Routing Engine on the protocol backup.

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.

In addition, the Junos XML protocol server returns the <commit-synchronize-server-success> tag element enclosing the information for the synchronize operation, which includes the estimated time in seconds required for the synchronize operation to complete.

The <commit-synchronize-server-success> element indicates that the synchronize operation has been scheduled. Junos OS records the UI_EPHEMERAL_COMMIT_SYNCHRONIZE_SUCCESS or the UI_EPHEMERAL_COMMIT_SYNCHRONIZE_FAILURE event in the system log file to record the success or failure of the synchronize operation.

Similarly, the NETCONF server confirms that the commit operation was successful by returning the <ok/> tag in an <rpc-reply> tag element in addition to the <commit-synchronize-server-success> element.

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

If graceful Routing Engine switchover (GRES) is configured on the device, you must configure the allow-commit-synchronize-with-gres statement at the [edit system configuration-database ephemeral] hierarchy level in the static configuration database to enable the device to synchronize an ephemeral instance to the other Routing Engine when you request a commit synchronize operation on the instance.

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

  1. Configure the allow-commit-synchronize-with-gres statement in the static configuration database.
  2. 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 master 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 master and backup Routing Engines, the backup Routing Engine synchronizes its configuration with the master 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 mastership

  • 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 master Routing Engine. In an MX Series Virtual Chassis, the master Routing Engine on the protocol backup synchronizes its configuration databases with the master Routing Engine on the protocol master.

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.