Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Understanding the Ephemeral Configuration Database

 

The ephemeral database is an alternate configuration database that provides a fast programmatic interface for performing configuration updates on devices running Junos OS. The ephemeral database enables Juniper Extension Toolkit (JET) applications and NETCONF and Junos XML management protocol client applications to concurrently load and commit configuration changes to a device running Junos OS and with significantly greater throughput than when committing data to the candidate configuration database.

The different aspects of the ephemeral configuration database are discussed in the following sections.

Ephemeral Configuration Database Overview

When managing devices running Junos OS, the recommended and most common method to configure the device is to modify and commit the candidate configuration, which corresponds to a persistent (static) configuration database. The standard Junos OS commit operation handles configuration groups, macros, and commit scripts; performs commit checks to validate the configuration’s syntax and semantics; and stores copies of the committed configurations. The standard commit model is robust, because it prevents configuration errors and enables you to roll back to a previously committed configuration. However, in some cases, the commit operation can consume a significant amount of time and device resources.

JET applications and NETCONF and Junos XML protocol client applications can also configure the ephemeral database. The ephemeral database is an alternate configuration database that provides a configuration layer separate from both the candidate configuration database and the configuration layers of other client applications. The ephemeral commit model enables devices running Junos OS to commit and merge changes from multiple clients and execute the commits with significantly greater throughput than when committing data to the candidate configuration database. Thus, the ephemeral database is advantageous in dynamic environments where fast provisioning and rapid configuration changes are required, such as in large data centers.

A commit operation on the ephemeral database requires less time than the same operation on the static database, because the ephemeral database is not subject to the same verification required in the static database. As a result, the ephemeral commit model provides better performance than the standard commit model but at the expense of some of the more robust features present in the standard model. The ephemeral commit model has the following restrictions:

  • Configuration data syntax is validated, but configuration data semantics are not validated.

  • Certain configuration statements are not supported as described in Unsupported Configuration Statements in the Ephemeral Configuration Database.

  • Configuration groups and interface ranges are not processed.

  • Macros, commit scripts, and translation scripts are not processed.

  • Previous versions of the ephemeral configuration are not archived.

  • Ephemeral configuration data does not persist across reboots.

  • Ephemeral configuration data does not persist when installing a package that requires rebuilding the Junos OS schema, for example, an OpenConfig or YANG package.

  • Ephemeral configuration data is not displayed in the normal configuration using standard show commands.

Caution

We strongly recommend that you exercise caution when using the ephemeral configuration database, because committing invalid configuration data can corrupt the ephemeral database, which can cause Junos OS processes to restart or even crash and result in disruption to the system or network.

Junos OS validates the syntax but not the semantics, or constraints, of the configuration data committed to the ephemeral database. For example, if the configuration references an undefined routing policy, the configuration might be syntactically correct, but it would be semantically incorrect. The standard commit model generates a commit error in this case, but the ephemeral commit model does not. Therefore, it is imperative to validate all configuration data before committing it to the ephemeral database. If you commit 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 all ephemeral configuration data.

Note

The ephemeral configuration database stores internal version information in addition to configuration data. As a result, the size of the ephemeral configuration database is always larger than the static configuration database for the same configuration data, and most operations on the ephemeral database, whether additions, modifications, or deletions, increase the size of the database.

Note

If the ephemeral configuration database is present on a device running Junos OS, commit operations on the static configuration database might take longer, because additional operations must be performed to merge the static and ephemeral configuration data.

Ephemeral Database Instances

Devices running Junos OS provide a default ephemeral database instance, which is automatically enabled, as well as the ability to enable user-defined instances of the ephemeral configuration database. JET applications and NETCONF and Junos XML protocol client applications can concurrently load and commit data to separate instances of the ephemeral database. The active device configuration is a merged view of the static and ephemeral configuration databases.

Note

Starting in Junos OS Release 18.2R1, devices running Junos OS support configuring up to seven user-defined instances of the ephemeral configuration database. In earlier releases, you can configure up to eight user-defined instances.

Ephemeral database instances are useful in scenarios where multiple client applications might need to simultaneously update a device configuration, such as when two or more SDN controllers simultaneously push configuration data to the same device. In the standard commit model, one controller might have an exclusive lock on the candidate configuration, thereby preventing the other controller from modifying it. By using separate ephemeral instances, the controllers can deploy the changes at the same time.

Note

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

The Junos OS processes read the configuration data from both the static configuration database and the ephemeral configuration database. When one or more ephemeral database instances are in use and there is conflicting data, statements in a database with a higher priority override those in a database with a lower priority. A user-defined instance of the ephemeral configuration database has higher priority than the default ephemeral database instance, which has higher priority than the static configuration database. If there are multiple user-defined ephemeral instances, the priority is determined by the order in which the instances are listed in the configuration at the [edit system configuration-database ephemeral] hierarchy level, running from highest to lowest priority.

Consider the following configuration:

Figure 1 illustrates the order of priority of the ephemeral database instances and the static (committed) configuration database. In this example, ephemeral database instance 1 has the highest priority, followed by ephemeral database instance 2, then the default ephemeral database instance, and finally the static configuration database.

Figure 1: Ephemeral Database Instances
Ephemeral
 Database Instances

Ephemeral Database General Commit Model

JET applications and NETCONF and Junos XML protocol client applications can modify the ephemeral configuration database. JET applications must send configuration requests as pairs of load and commit operations. NETCONF and Junos XML protocol client applications can perform multiple load operations before executing a commit operation. If a client disconnects from a session, Junos OS discards any uncommitted configuration changes in the ephemeral instance, but configuration data that has already been committed to the ephemeral instance by that client is unaffected.

Client applications can simultaneously load and commit data to different instances of the ephemeral database. Commits issued at the same time for different ephemeral instances are queued and processed serially by the device. When you commit an ephemeral instance, Junos OS validates the syntax, but not the semantics, of the configuration data committed to the ephemeral database. When the commit is complete, Junos OS notifies the affected system processes, which read the updated configuration and merge the ephemeral data into the active configuration according to the rules of prioritization described in Ephemeral Database Instances. The active device configuration is a merged view of the static and ephemeral configuration databases.

Caution

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.

For detailed information about committing and synchronizing instances of the ephemeral configuration database, see Committing and Synchronizing Ephemeral Configuration Data Using the NETCONF or Junos XML Protocol.

Ephemeral Database Commit Model on Devices that Use High Availability Features

High availability refers to the hardware and software components that provide redundancy and reliability for network communications. There are certain behaviors and caveats that should be considered before using the ephemeral database on systems that use high availability features, including redundant Routing engines, graceful Routing Engine switchover (GRES), nonstop active routing (NSR), and interchassis redundancy for MX Series routers using Virtual Chassis. The following sections describe these behaviors.

Redundant Routing Engines

Dual Routing Engine systems support configuring the ephemeral database. However, when dual Routing Engines are present, the ephemeral commit model does not automatically synchronize ephemeral configuration data to the backup Routing Engine during a commit operation. Client applications can synchronize the data in an ephemeral instance on a per-commit or per-session basis.

Unlike the standard commit model, the ephemeral commit model performs commit synchronize operations asynchronously. 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.

For more information, see Committing and Synchronizing Ephemeral Configuration Data Using the NETCONF or Junos XML Protocol.

Note

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

Starting in Junos OS Release 20.2R1, dual Routing Engine devices support failover configuration synchronization for the ephemeral database. When you configure the commit synchronize statement at the [edit system] hierarchy level in the static configuration database and the backup Routing Engine synchronizes with the master Routing Engine, for example, when it is newly inserted, brought back online, or during a change in mastership, it synchronizes both its static and ephemeral configuration databases. In earlier release, the backup Routing Engine only synchronizes its static configuration database.

Graceful Routing Engine Switchover (GRES)

Graceful Routing Engine switchover enables a device with redundant Routing Engines to continue forwarding packets, even if one Routing Engine fails. GRES requires that the master and backup Routing Engines synchronize the configuration and certain state information before a switchover occurs.

We do not recommend using the ephemeral database on devices that have GRES enabled, because in certain circumstances, the ephemeral database might not be synchronized between the master and backup Routing Engines when a switchover occurs. For example, because commit synchronize operations on the ephemeral database are asynchronous, the backup and master Routing Engines might not synchronize if the operation is interrupted by a sudden power outage. Furthermore, on devices running Junos OS Release 20.1 and earlier, when the backup Routing Engine synchronizes its configuration with the master Routing Engine, it does not synchronize the ephemeral configuration database as described in Redundant Routing Engines. Thus, if the backup Routing Engine restarts, for example, it deletes the ephemeral configuration data, which does not persist across reboots, and it does not automatically synchronize the database again when it comes online. As a result, the ephemeral database might not be synchronized between the backup and master Routing Engines when a switchover occurs.

When GRES is enabled, you must explicitly 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 ephemeral configuration data to the backup Routing Engine when you request a commit synchronize operation on an ephemeral instance. If GRES is enabled, and you do not configure the allow-commit-synchronize-with-gres statement, the device does not synchronize the ephemeral instance to the backup Routing Engine when you request a commit synchronize operation on that instance.

Nonstop active routing (NSR)

We do not recommend using the ephemeral database on devices running Junos OS that have nonstop active routing (NSR) enabled, because it comes with certain caveats. In a deployment with dual Routing Engines, a commit synchronize operation on an ephemeral instance on the master Routing Engine results in an asynchronous commit on the backup Routing Engine. If the device notifies the routing protocol process (rpd) in the process of updating the configuration, it could result in an undesirable behavior of the system due to the asynchronous nature of the commit on the backup Routing Engine. The processes that are notified during the ephemeral database update depend on the Junos OS release.

When you update an ephemeral instance on the master Routing Engine, the change on the backup Routing Engine overrides the complete configuration for the ephemeral instance, replacing it with the latest. In Junos OS Release 20.1 and earlier, when the new configuration is applied on the backup Routing Engine, Junos OS notifies all system processes that have statements in that ephemeral instance. Starting in Junos OS Release 20.2R1, the behavior of the ephemeral database is enhanced. If the ephemeral instance is already synchronized between the master and backup Routing Engines, and you update the ephemeral instance on the master Routing Engine, Junos OS only notifies those processes corresponding to the modified portions of the ephemeral instance configuration when it commits the changes on the backup Routing Engine.

Note

Applications utilizing the ephemeral database are only impacted in this NSR situation if they interact with the routing protocol process. For example, the SmartWall Threat Defense Director (SmartWall TDD) would not be impacted in this case, because it only interacts with the firewall process (dfwd) through the ephemeral database.

MX Series Virtual Chassis

Starting in Junos OS Release 20.2R1, MX Series Virtual Chassis support configuring the ephemeral database. In a Virtual Chassis configuration, you can only configure and commit an ephemeral instance on the master Routing Engine of the protocol master.

An MX Series Virtual Chassis does not automatically synchronize any ephemeral configuration data during a commit operation. As with dual Routing Engine systems, you can synchronize the data in an ephemeral instance on a per-commit or per-session basis, or you can configure an instance to synchronize the data every time the instance is committed. The ephemeral data is only synchronized from the master Routing Engine on the protocol master to the master Routing Engine on the protocol backup. Because MX Series Virtual Chassis must have GRES configured, you must explicitly configure the allow-commit-synchronize-with-gres statement in the static configuration database to enable the device to synchronize ephemeral configuration data during a commit synchronize operation.

Note

MX Series Virtual Chassis do not, under any circumstance, synchronize ephemeral configuration data from the master Routing Engine to the backup Routing Engine on the respective Virtual Chassis member.

When you execute a commit synchronize operation on an ephemeral instance in an MX Series Virtual Chassis:

  1. The protocol master validates the syntax and commits the ephemeral instance on its master Routing Engine.

  2. If the commit is successful, the protocol master notifies the protocol backup to synchronize the ephemeral instance.

  3. The protocol backup commits the ephemeral instance on its master Routing Engine only. If the commit operation fails, the protocol backup logs a message in the system log file but does not notify the protocol master.

As outlined, the commit operation on the protocol master and protocol backup is asynchronous. The protocol master commits the ephemeral instance on its master Routing Engine, and then notifies the protocol backup to commit the data on its master Routing Engine. If the protocol master’s commit operation fails, it does not notify the protocol backup, and the ephemeral instance is not committed on either member. However, if the protocol master’s commit operation succeeds, but the protocol backup’s commit operation fails, the protocol master is unaffected.

MX Series Virtual Chassis support failover configuration synchronization for the ephemeral database. When you configure the commit synchronize statement at the [edit system] hierarchy level in the static configuration database, and the master Routing Engine on the protocol backup synchronizes with the master Routing Engine on the protocol master, for example after it restarts, its synchronizes both its static and ephemeral configuration databases.

Release History Table
Release
Description
When you configure the commit synchronize statement at the [edit system] hierarchy level in the static configuration database and the backup Routing Engine synchronizes with the master Routing Engine, for example, when it is newly inserted, brought back online, or during a change in mastership, it synchronizes both its static and ephemeral configuration databases.
Starting in Junos OS Release 18.2R1, devices running Junos OS support configuring up to seven user-defined instances of the ephemeral configuration database. In earlier releases, you can configure up to eight user-defined instances.