Committing the Candidate Configuration Using NETCONF
When you commit the candidate configuration on a device running Junos OS, it becomes the active configuration on the routing, switching, or security platform. For more detailed information about commit operations, including a discussion of the interaction among different variants of the operation, see the CLI User Guide.
In a NETCONF session with a device running Junos OS,
to commit the candidate configuration, a client application encloses
<commit/> tag in an
<rpc> tag element.
We recommend that the client application lock the candidate
configuration before modifying it and emit the
<commit/> 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.
The NETCONF server confirms that the commit operation
was successful by returning the
<ok/> tag in the
<rpc-reply> tag element.
If the commit operation fails, the server returns the
<rpc-reply> element and
<rpc-error> child element, which explains the reason for the failure. The most
common causes are semantic or syntactic errors in the candidate configuration.
In certain situations, if the commit operation succeeds but
also returns a warning, the RPC reply includes both an
<rpc-error> element with a severity level of warning
<ok/> element. Starting in Junos
OS Release 17.4R3, 18.2R2, 18.3R2, and 18.4R1, when you configure
the rfc-compliant statement at the [edit system services
netconf] hierarchy level to enforce certain behaviors by the
NETCONF server, the NETCONF server cannot return an RPC reply that
includes both an
<ok/> element. In this case,
if the operation is successful but the server reply would include
one or more
<rpc-error> elements with
a severity level of warning in addition to the
<ok/> element, then the warnings are omitted.