Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

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 or Junos OS Evolved. 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 and with significantly greater throughput than when committing data to the candidate configuration database.

The following sections discuss the different aspects of the ephemeral configuration database.

Benefits of the Ephemeral Configuration Database

  • Enables multiple client applications to concurrently configure a device by loading and committing data to separate instances of the ephemeral database
  • Enables fast provisioning and rapid configuration changes in dynamic environments that require fast commit times

Ephemeral Configuration Database Overview

When managing Junos devices, 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 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 Junos devices 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 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 processes to restart or even crash and result in disruption to the system or network.

Junos devices validate 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:

When you use the ephemeral configuration database, 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

Junos devices 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, Junos OS supports configuring up to seven user-defined instances of the ephemeral configuration database. In earlier releases, you can configure up to eight user-defined instances. Junos OS Evolved supports configuring 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 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 the statements in a database with a lower priority. 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.

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.

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 processes to restart or even crash and result in disruption to the system or network.

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. If a client disconnects from a session, the device 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.

When you commit an ephemeral instance, the system validates the syntax, but not the semantics, of the ephemeral configuration data. When the commit is complete, the device notifies the affected system processes. The processes 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.

Note:

The ephemeral database's commit time will be slightly longer on devices running Junos OS Evolved than on devices running Junos OS because of the architectural differences between the two operating systems.

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

Using the Ephemeral Database 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 and outline how the different ephemeral database commit synchronize models can affect these behaviors.

Understanding Ephemeral Database Commit Synchronize Models

Unlike the standard commit model, the default ephemeral commit model executes 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. Devices that use high availability features require that the primary and backup Routing Engines are synchronized in case of a failover. However, there can be situations in which an asynchronous commit synchronize operation can be interrupted and fail to synchronize the ephemeral configuration to the other Routing Engine.

On devices running Junos OS Release 21.1R1 or later and devices running Junos OS Evolved, you can configure the ephemeral database to execute commit synchronize operations using a synchronous commit model, similar to that used by the static configuration database. In the synchronous commit model:

  1. The primary Routing Engine starts its initial commit operation for the ephemeral instance.
  2. At a given point during its commit operation, the primary Routing Engine initiates a commit on the backup Routing Engine.
  3. If the backup Routing Engine successfully commits the configuration, then the primary Routing Engine continues its commit operation. If the commit fails on the backup Routing Engine, then the primary Routing Engine also fails the commit.

Synchronous commit operations are slower than asynchronous commit operations, but they provide better assurance that the ephemeral configuration is synchronized between Routing Engines. The synchronous commit model enables you to use the ephemeral database with greater reliability on devices that also use high availability features.

Note:

As is the case for the static configuration database, even with the synchronous commit synchronize model, there can be rare circumstances in which the device commits an updated ephemeral configuration on the backup Routing Engine but fails to complete the commit on the primary Routing Engine resulting in the configurations being out of synchronization.

To enable the synchronous commit synchronize model for the ephemeral configuration database, configure the commit-synchronize-model synchronous statement at the [edit system configuration-database ephemeral] hierarchy level in the static configuration database.

Devices running Junos OS Release 20.2R1 or later and devices running Junos OS Evolved also support failover configuration synchronization for the ephemeral database. When you configure failover synchronization and the backup Routing Engine synchronizes with the primary Routing Engine, for example, when it is newly inserted, brought back online, or during a change in role, it synchronizes both its static and ephemeral configuration databases. In earlier Junos OS releases, the backup Routing Engine only synchronizes its static configuration database. To enable failover synchronization, configure the commit synchronize statement at the [edit system] hierarchy level in the static configuration database.

On devices running Junos OS Release 21.1R1 or later and devices running Junos OS Evolved, both commit synchronize operations and failover synchronize operations synchronize the ephemeral configuration data to the other Routing Engine using a load update operation instead of a load override operation. By using a load update operation, the device only needs to notify the Junos processes that correspond to changed statements during the update, which minimizes possible disruptions to the network.

Redundant Routing Engines

Dual Routing Engine systems support configuring the ephemeral database. However, 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, or they can configure an ephemeral instance to automatically synchronize its data every time the instance is committed. For more information, see Commit and Synchronize 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.

When a client application commits data in an ephemeral instance and synchronizes it to the backup Routing Engine, by default, the ephemeral database performs the commit synchronize operation asynchronously. You can configure the ephemeral database to use a synchronous commit model for commit synchronize operations. In addition, dual Routing Engine devices also support failover configuration synchronization for the ephemeral database starting in Junos OS Release 20.2R1. For more information, see Understanding Ephemeral Database Commit Synchronize Models.

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 primary and backup Routing Engines synchronize the configuration and certain state information before a switchover occurs.

By default, the ephemeral database performs commit synchronize operations asynchronously. On supported devices running Junos OS Release 21.1R1 or later and devices running Junos OS Evolved, you can configure the ephemeral database to perform commit synchronize operations using a synchronous commit model as described in Understanding Ephemeral Database Commit Synchronize Models. We recommend that you use the synchronous commit model on devices that have GRES enabled, when the device does not have strict requirements on commit times. Synchronous commit operations are slower than asynchronous commit operations, but they provide better assurance that the ephemeral configuration is synchronized between Routing Engines. Thus, with this commit model, you can use the ephemeral database with greater reliability on devices that have GRES enabled.

Note:

Dual Routing Engine devices running Junos OS Evolved enable GRES by default.

We do not recommend using the ephemeral database with the asynchronous commit synchronize model on devices that have GRES enabled, because in certain circumstances, the ephemeral database might not be synchronized between the primary and backup Routing Engines when a switchover occurs. For example, the backup and primary Routing Engines might not synchronize the ephemeral database if the commit synchronize 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 primary Routing Engine, it does not synchronize the ephemeral configuration database. 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 primary Routing Engines when a switchover occurs.

When GRES is enabled and the ephemeral database uses the asynchronous commit model, which is the default, 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, devices using the asynchronous commit model do not synchronize the ephemeral instance to the backup Routing Engine when you request a commit synchronize operation on that instance.

Nonstop Active Routing (NSR)

By default, the ephemeral database performs commit synchronize operations asynchronously. On supported devices running Junos OS Release 21.1R1 or later and devices running Junos OS Evolved, you can configure the ephemeral database to perform commit synchronize operations using a synchronous commit model as described in Understanding Ephemeral Database Commit Synchronize Models. We recommend that you use the synchronous commit model on devices that have nonstop active routing (NSR) enabled. Synchronous commit operations are slower than asynchronous commit operations, but they provide better assurance that the ephemeral configuration is synchronized between Routing Engines. Thus, with this commit model, you can use the ephemeral database with greater reliability on devices that have NSR enabled.

We do not recommend using the ephemeral database with the asynchronous commit synchronize model on devices that have 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 primary 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 when an ephemeral instance is synchronized to the backup Routing Engine depend on the Junos OS release. In Junos OS Release 20.4 and earlier, when you update an ephemeral instance on the primary 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 primary and backup Routing Engines, and you update the ephemeral instance on the primary 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. Starting in Junos OS Release 21.1R1, the device synchronizes the ephemeral instance to the backup Routing Engine using a load update operation instead of a load override operation, so it only notifies processes corresponding to statements that are changed.

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. You can only configure and commit an ephemeral instance on the primary Routing Engine of the Virtual Chassis primary device.

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 ephemeral instance to automatically synchronize its data every time the instance is committed. The ephemeral data is only synchronized from the primary Routing Engine on the primary device to the primary Routing Engine on the backup device.

Note:

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

MX Series Virtual Chassis must have GRES configured. If you configure the ephemeral database to use the synchronous commit synchronize model, the device synchronizes the ephemeral instance to the other Routing Engine when you request a commit synchronize operation. However, if the ephemeral database uses the default asynchronous commit synchronize model, 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. See Understanding Ephemeral Database Commit Synchronize Models for more information about the ephemeral database commit models.

When you commit and synchronize an ephemeral instance on an MX Series Virtual Chassis that uses the asynchronous commit synchronize model:

  1. The Virtual Chassis primary device validates the syntax and commits the ephemeral instance on its primary Routing Engine.

  2. If the commit is successful, the primary device notifies the backup device to synchronize the ephemeral instance.

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

When you commit and synchronize an ephemeral instance on an MX Series Virtual Chassis that is configured to use the synchronous commit synchronize model:

  1. The Virtual Chassis primary device starts its commit of the ephemeral instance on its primary Routing Engine.

  2. At a given point in its commit operation, the primary device initiates a commit on the backup device's primary Routing Engine.

  3. If the backup device successfully commits the configuration, then the primary device continues its commit operation. If the backup device fails to commit the configuration, then the primary device also fails the commit.

As outlined, when you use the asynchronous commit synchronize model for the ephemeral database, the commit can succeed on the primary device but fail on the backup device. When you use the synchronous commit synchronize model, the commit either succeeds or fails for both primary Routing Engines, except in rare circumstances.

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 primary Routing Engine on the Virtual Chassis backup device synchronizes with the primary Routing Engine on the Virtual Chassis primary device, for example after it restarts, its synchronizes both its static and ephemeral configuration databases.

Related Documentation

Release History Table
Release
Description
20.2R1
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 primary Routing Engine, for example, when it is newly inserted, brought back online, or during a change in role, it synchronizes both its static and ephemeral configuration databases.
18.2R1
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.