Committing and Synchronizing a Configuration on Redundant Control Planes

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 master plane and the backup plane. In multichassis configurations, the control plane includes all Routing Engines with the same Routing Engine designation. For example, all master Routing Engines reside within the master 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 master and the slave control planes. When issued, this command will save the current configuration to both device Engines and commit the new configuration to both control planes. On a multichassis system, once the configuration has been committed on both planes, the distribution function will distribute the new configuration across both planes. For more information on Routing Engine redundancy, see the Junos High Availability Configuration 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 each plane 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, swtiching, or security platform. For more information about configuration groups, see the Junos CLI User Guide.

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

For more information about synchronizing configurations, see the following sections:

Synchronizing the Configuration on Both Routing Engines

To synchronize a configuration on a redundant Routing Engine system, a client application needs to enclose the empty <synchronize/> tag in <commit-configuration> and <rpc> tag elements:

<rpc>
    <commit-configuration>
        <synchronize/> 
    </commit-configuration>
</rpc>

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):
```
<routing-engine>
    <name>(re0 | re1)</name>
    <commit-check-success/>
</routing-engine>
```
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:
```
<routing-engine>
    <name>(re0 | re1)</name>
    <commit-success/>
</routing-engine>
```
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.

Example: Synchronizing the Configuration on Both Routing Engines

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 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 <commit-configuration> and <rpc> tag elements:

<rpc>
    <commit-configuration>
        <synchronize/>
        <force-synchronize/>
    </commit-configuration>
</rpc>

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.

Example: Forcing a Synchronization

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 Configurations 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:

<rpc>
    <commit-configuration>
        <synchronize/> 
        <check/> 
    </commit-configuration>
</rpc>

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

For more information about verifying configurations, see Verifying a Configuration Before Committing It.

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:

<rpc>
    <commit-configuration>
        <synchronize/> 
        <at-time>time</at-time> 
    </commit-configuration>
</rpc>
     
<rpc>
    <commit-configuration>
        <force-synchronize/>
        <at-time>time</at-time>
    </commit-configuration>
</rpc>

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. For information about how to specify the time in the <at-time> tag element, see Committing the Candidate Configuration Only After Confirmation.

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:

<rpc>
    <commit-configuration>
        <synchronize/> 
        <confirmed/> 
            [<confirm-timeout>minutes</confirm-timeout>] 
    </commit-configuration>
</rpc>

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.

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:

<rpc>
    <commit-configuration>
        <synchronize/> 
        <log>message</log> 
    </commit-configuration>
</rpc>

<rpc>
    <commit-configuration>
        <force-synchronize/>
        <log>message</log>
    </commit-configuration>
</rpc>

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 separate /var/log/commits file maintained by that Routing Engine. For more information about logging, see Logging a Message About a Commit Operation.