Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 

Committing the Candidate Configuration Using the Junos XML Protocol

 

When you commit the candidate configuration on a device running Junos OS, it becomes the active configuration on the routing, switching, or security platform. In a Junos XML protocol session, to commit the candidate configuration, a client application encloses the empty <commit-configuration/> tag in an <rpc> tag element.

We recommend that the client application lock the candidate configuration before modifying it and emit the <commit-configuration/> tag while the configuration is still locked. This process avoids inadvertently committing changes made by other users or applications. After committing the configuration, the application must unlock it in order for other users and applications to make changes. For instructions, seeLocking and Unlocking the Candidate Configuration or Creating a Private Copy Using the Junos XML Protocol.

The Junos XML protocol server reports the results of the commit operation in <rpc-reply>, <commit-results>, and <routing-engine> tag elements. If the commit operation succeeds, 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 (re0 on devices that use a single Routing Engine, and either re0 or re1 on devices that can have two Routing Engines).

If the commit operation fails, the server returns an <xnm:error> tag element, which encloses child tag elements that describe the error. The most common causes of failure are semantic or syntactic errors in the candidate configuration.