Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Commit and Synchronize a Configuration on Redundant Control Planes Using the Junos XML Protocol

A Routing Engine resides within a control plane. For single-chassis configurations, there is one control plane. In redundant systems, there are two control planes, the primary plane and the backup plane. In multichassis configurations, the control plane includes all Routing Engines with the same Routing Engine designation. For example, all primary Routing Engines reside within the primary control plane, and all backup Routing Engines reside within the backup control plane.

Committing a configuration applies a new configuration to the device Engine. In a multichassis configuration, once a change to the configuration has been committed to the system, this change is propagated throughout the control plane using the distribution function.

In a redundant architecture, you can issue the synchronize command to commit the new configuration to both the primary and the backup control planes. When issued, this command saves the current configuration to both device Routing Engines and commits the new configuration to both control planes. On a multichassis system, once the configuration has been committed on both planes, the distribution function distributes the new configuration across both planes. For more information about Routing Engine redundancy, see the Junos OS High Availability User Guide.

Note:

In a multichassis architecture with redundant control planes, there is a difference between synchronizing the two planes and distributing the configuration throughout each plane. Synchronization only occurs between the Routing Engines within the same chassis. Once this synchronization is complete, the new configuration is distributed to all other Routing Engines within the control planes of other chassis as a separate distribution function.

Because synchronization happens across two separate control planes, synchronizing configurations is only valid on redundant Routing Engine architectures. Further, re0 and re1 configuration groups must be defined on each routing, switching, or security platform. For more information about configuration groups, see the CLI User Guide.

Note:

If you issue the synchronize command on a nonredundant Routing Engine system, the Junos XML protocol server commits the configuration on the one control plane.

For information about synchronizing the ephemeral configuration database, see Committing and Synchronizing Ephemeral Configuration Data Using the NETCONF or Junos XML Protocol. For more information about synchronizing the candidate configuration, see the following sections:

Synchronizing the Candidate Configuration on Both Routing Engines

To synchronize the candidate configuration or private copy on a redundant Routing Engine system, a client application encloses the empty <synchronize/> tag in <commit-configuration> and <rpc> tag elements:

The Junos XML protocol server verifies the configuration’s syntactic correctness on the Routing Engine where the <synchronize/> tag is emitted (referred to as the local Routing Engine), copies the configuration to the remote Routing Engine and verifies its syntactic correctness there, and then commits the configuration on both Routing Engines.

The Junos XML protocol server encloses its response in <rpc-reply> and <commit-results> tag elements. It emits a separate <routing-engine> tag element for each operation on each Routing Engine:

  • If the syntax check succeeds on a Routing Engine, the <routing-engine> tag element encloses the <commit-check-success/> tag and the <name> tag element, which reports the name of the Routing Engine on which the check succeeded (re0 or re1):

    If the configuration is incorrect, an <xnm:error> tag element encloses a description of the error.

  • If the commit operation succeeds on a Routing Engine, 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:

    If the commit operation fails, an <xnm:error> tag element encloses a description of the error. The most common causes of failure are semantic or syntactic errors in the configuration.

The following example shows how to commit and synchronize the candidate configuration on both Routing Engines.

Forcing a Synchronized Commit Operation

The synchronize operation fails if the second Routing Engine's candidate configuration is locked. If a synchronization failure occurs, it is best to determine the cause of the failure, take corrective action, and then synchronize the two Routing Engines again. However, when necessary, you can use the <force-synchronize/> command to override a locked configuration and force the synchronization.

Note:

When you use a force-synchronize command, any uncommitted changes to the configuration will be lost.

To force a synchronization, enclose the empty <synchronize/> and <force-synchronize/> tags in the <rpc> and <commit-configuration> tag elements:

Note:

In a multichassis environment, synchronization occurs between Routing Engines on the same chassis. Once the synchronization occurs, the configuration changes are propagated across each control plane using the distribution function. If one or more Routing Engines are locked during the distribution of the configuration, the distribution and thus the synchronization will fail. You will need to clear the error in the remote chassis and run the synchronize command again.

The following example shows how to force a synchronization across both Routing Engine planes:

Client Application

Junos XML Protocol Server

 
<rpc>
    <commit-configuration>
        <synchronize/>
        <force-synchronize/>
    </commit-configuration>
</rpc>
  
<rpc-reply xmlns:junos=
             "http://xml.juniper.net/junos/9.010/junos">
    <commit-results>
       <routing-engine junos:style="show-name">
            <name>re0</name>
            <commit-check-success/>
        </routing-engine>
       <routing-engine junos:style="show-name">
            <name>re1</name>
            <commit-success/>
        </routing-engine>
       <routing-engine junos:style="show-name">
            <name>re0</name>
            <commit-success/>
        </routing-engine>
    </commit-resuls>
</rpc-reply>

Synchronizing the Candidate Configuration Simultaneously with Other Operations

The <synchronize/> tag can be combined with the other tag elements that can occur within the <commit-configuration> tag element. The Junos XML protocol server checks, copies, and commits the configuration, and emits the same response tag elements as when the <synchronize/> tag is used by itself. The possible combinations are described in the following sections.

Verifying the Configuration on Both Routing Engines

To check the syntactic correctness of a local configuration on both Routing Engines without committing it, the application encloses the <synchronize/> and <check/> tag elements in <commit-configuration> and <rpc> tag elements:

The <force-synchronize/> tag cannot be combined with the <check/> tag elements.

For more information about verifying configurations, see Verifying Configuration Syntax Using the Junos XML Protocol.

Scheduling Synchronization for a Specified Time

To commit a configuration on both Routing Engines at a specified time in the future, the application encloses the <synchronize/> and <at-time> tag elements in <commit-configuration> and <rpc> tag elements:

As when the <at-time> tag element is emitted by itself, the Junos XML protocol server verifies syntactic correctness immediately and does not emit additional tag elements when it actually performs the commit operation on each Routing Engine.

Synchronizing Configurations but Requiring Confirmation

To commit the candidate configuration on both Routing Engines but require confirmation for the commit to become permanent, the application encloses the <synchronize/>, <confirmed/>, and (optionally) <confirm-timeout> tag elements in <commit-configuration> and <rpc> tag elements:

The same rollback deadline applies to both Routing Engines and can be extended on both at once by again emitting the <synchronize/>, <confirmed/>, and (optionally) <confirm-timeout> tag elements on the Routing Engine where the tag elements were emitted the first time.

The <force-synchronize/> tag cannot be combined with the <confirmed/> and <confirm-timeout> tag elements.

For more information about confirmed commit operations, see Committing the Candidate Configuration Only After Confirmation Using the Junos XML Protocol.

Logging a Message About Synchronized Configurations

To synchronize configurations and record a log message when the commit succeeds on each Routing Engine, the application encloses the <synchronize/> and <log/> tag elements in <commit-configuration> and <rpc> tag elements:

The commit operation proceeds as previously described in the <synchronize/> or <force-synchronize/> tag descriptions. The message for each Routing Engine is recorded in the commit history log maintained by that Routing Engine. For more information about logging, see Logging a Message About a Commit Operation Using the Junos XML Protocol.

Related Documentation