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.
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.
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.
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 define 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.
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.
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.
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.
Ephemeral Database 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. By default, 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.
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.
During the commit operation, 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.
When dual Routing Engines are present, the ephemeral commit model does not automatically synchronize ephemeral configuration data on the backup Routing Engine. Client applications can elect to synchronize the data in an ephemeral instance on a per-commit basis or every time the instance is committed. 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.
Multichassis and virtual chassis environments do not support synchronizing the ephemeral configuration database to the other Routing Engines.
Graceful Routing Engine switchover (GRES) enables a routing platform with redundant Routing Engines to continue forwarding packets, even if one Routing Engine fails. GRES requires that the configuration and certain state information are synchronized between the master and backup Routing Engines before a switchover occurs. Because of the synchronization requirements, 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.
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 failover or power outage. Furthermore, if the backup Routing Engine restarts, its ephemeral configuration data is deleted, because ephemeral data does not persist across reboots. When GRES is enabled and the backup Routing Engine restarts for any reason, its static configuration database is automatically synchronized with the database on the master Routing Engine, but the ephemeral configuration database is not synchronized.
When GRES is enabled on devices running Junos OS, the ephemeral configuration is not automatically synchronized to the backup Routing Engine when a commit synchronize operation is requested. If you elect to use the ephemeral database with the aforementioned caveats 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 when a commit synchronize operation is requested. If GRES is enabled, and you do not configure the allow-commit-synchronize-with-gres statement, the device does not synchronize ephemeral configuration data under any circumstance.
For detailed information about committing and synchronizing instances of the ephemeral configuration database, see the following topics:
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, any configuration change in an ephemeral instance on the master Routing Engine results in a configuration change on the backup Routing Engine. The change on the backup Routing Engine is asynchronous and also overrides the complete active configuration, replacing it with the latest. When the new configuration is applied on the backup Routing Engine, Junos OS notifies all system processes that have statements in the latest configuration. If the routing protocol process (rpd) is notified, it may result in an undesirable behavior of the system.
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.