Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Change Individual Configuration Elements Using NETCONF

In a NETCONF session with a device running Junos OS, a client application can change individual configuration elements in the existing configuration by using the <edit-config> tag element. By default, the NETCONF server merges new configuration data into the existing configuration. However, a client application can also replace, create, or delete individual configuration elements (hierarchy levels or configuration objects). The same basic tag elements are emitted for all operations: <config>, <config-text>, or <url> tag sub-elements within the <edit-config> tag element.

Within the <edit-config> element, the <target> element encloses the <candidate/> tag, which can refer to either the candidate configuration or the open configuration database. If a client application issues the Junos XML protocol <open-configuration> operation to open a specific configuration database before executing the <edit-config> operation, Junos OS performs the operation on the open configuration database. Otherwise, the operation is performed on the candidate configuration.

The application includes the configuration data within the <config> or <config-text> tag elements or in the file specified by the <url> tag element. To define a configuration element, the application includes the tag elements representing all levels of the configuration hierarchy from the root down to the immediate parent level for the element. To represent the element, the application includes its container tag element. The child tags included within the container element depend on the operation.

For more information about the tag elements that represent configuration statements, see Map Configuration Statements to Junos XML Tag Elements. For information about the tag elements for a specific configuration element, see the Junos XML API Configuration Developer Reference.

The NETCONF server indicates that it changed the configuration in the requested way by enclosing the <ok/> tag in the <rpc-reply> tag element: