- play_arrow Overview
- play_arrow Junos XML Management Protocol and Junos XML API Overview
- play_arrow Junos XML Protocol and Junos XML Tags Overview
- XML and Junos OS Overview
- XML Overview
- XML and Junos XML Management Protocol Conventions Overview
- Map Junos OS Commands and Command Output to Junos XML Tag Elements
- Map Configuration Statements to Junos XML Tag Elements
- Using Configuration Response Tag Elements in Junos XML Protocol Requests and Configuration Changes
- play_arrow Junos XML Protocol and JSON Overview
-
- play_arrow Manage Junos XML Protocol Sessions
- play_arrow Junos XML Protocol Session Overview
- play_arrow Manage Junos XML Protocol Sessions
- Satisfy the Prerequisites for Establishing a Connection to the Junos XML Protocol Server
- Configure clear-text or SSL Service for Junos XML Protocol Client Applications
- Connect to the Junos XML Protocol Server
- Start a Junos XML Protocol Session
- Authenticate with the Junos XML Protocol Server for Cleartext or SSL Connections
- Send Requests to the Junos XML Protocol Server
- Parse the Junos XML Protocol Server Response
- Parse Response Tag Elements Using a Standard API in NETCONF and Junos XML Protocol Sessions
- How Character Encoding Works on Juniper Networks Devices
- Handle an Error or Warning in Junos XML Protocol Sessions
- Halt a Request in Junos XML Protocol Sessions
- Lock, Unlock, or Create a Private Copy of the Candidate Configuration Using the Junos XML Protocol
- Terminate a Junos XML Protocol Session
- End a Junos XML Protocol Session and Close the Connection
- Sample Junos XML Protocol Session
- play_arrow Junos XML Protocol Tracing Operations
- play_arrow Junos XML Protocol Operations
- play_arrow Junos XML Protocol Processing Instructions
- play_arrow Junos XML Protocol Response Tags
- play_arrow Junos XML Element Attributes
- active
- count
- delete
- inactive
- insert
- junos:changed
- junos:changed-localtime
- junos:changed-seconds
- junos:commit-localtime
- junos:commit-seconds
- junos:commit-user
- junos:group
- junos:interface-range
- junos:key
- junos:position
- junos:total
- matching
- protect
- recurse
- rename
- replace
- replace-pattern
- start
- unprotect
- xmlns
-
- play_arrow Request Operational and Configuration Information Using the Junos XML Protocol
- play_arrow Request Operational Information Using the Junos XML Protocol
- play_arrow Request Configuration Information Using the Junos XML Protocol
- Request Configuration Data Using the Junos XML Protocol
- Specify the Source for Configuration Information Requests in a Junos XML Protocol Session
- Specify the Output Format for Configuration Data in a Junos XML Protocol Session
- Request Commit-Script-Style XML Configuration Data Using the Junos XML Protocol
- Specify the Output Format for Configuration Groups and Interface Ranges Using the Junos XML Protocol
- Request Identifier Indicators for Configuration Elements Using the Junos XML Protocol
- Request Change Indicators for Configuration Elements Using the Junos XML Protocol
- Specify the Scope of Configuration Data to Return in a Junos XML Protocol Session
- Request the Complete Configuration Using the Junos XML Protocol
- Request a Configuration Hierarchy Level or Container Object Without an Identifier Using the Junos XML Protocol
- Request All Configuration Objects of a Specific Type Using the Junos XML Protocol
- Request a Specific Number of Configuration Objects Using the Junos XML Protocol
- Request Identifiers for Configuration Objects of a Specific Type Using the Junos XML Protocol
- Request a Single Configuration Object Using the Junos XML Protocol
- Request Subsets of Configuration Objects Using Regular Expressions
- Request Multiple Configuration Elements Using the Junos XML Protocol
- Retrieve a Previous (Rollback) Configuration Using the Junos XML Protocol
- Retrieve the Rescue Configuration Using the Junos XML Protocol
- Compare the Active or Candidate Configuration to a Prior Version Using the Junos XML Protocol
- Compare Two Previous (Rollback) Configurations Using the Junos XML Protocol
- Request an XML Schema for the Configuration Hierarchy Using the Junos XML Protocol
-
- play_arrow Junos XML Protocol Utilities
- play_arrow Develop Junos XML Protocol C Client Applications
-
- play_arrow Configuration Statements and Operational Commands
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.
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.
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:
<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):content_copy zoom_out_map<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:content_copy zoom_out_map<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.
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.
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:
<rpc> <commit-configuration> <synchronize/> <force-synchronize/> </commit-configuration> </rpc>
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:
<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 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:
<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.
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 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:
<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 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.