Delete Configuration Elements Using NETCONF
Delete configuration elements
You can use NETCONF to delete configuration elements, including hierarchy levels or configuration objects, from the Junos configuration. You can delete objects from the candidate configuration or the open configuration database (if the client application issued the Junos XML protocol <open-configuration> operation prior to executing the <edit-config> operation).
To delete an element, a client application emits the basic tag elements described in Change Individual Configuration Elements Using NETCONF. It also emits the <default-operation> tag element with the value none to change the default mode to no-change.
<rpc> <edit-config> <target> <candidate/> </target> <default-operation>none</default-operation> <!-- EITHER --> <config> <configuration> <!-- tag elements representing the configuration elements to delete --> </configuration> </config> <!-- OR --> <url> <!-- location specifier for file containing elements to delete --> </url> </edit-config> </rpc> ]]>]]>
In no-change mode, existing configuration elements remain unchanged unless the corresponding element in the new configuration has the operation="delete" attribute or operation="remove" attribute in its opening tag. This mode prevents the NETCONF server from creating parent hierarchy levels for an element that is being deleted. We recommend that client applications only perform deletion operations when using no-change mode. When merging, replacing, or creating configuration elements, client applications use merge mode.
The delete and remove attributes both instruct the NETCONF server to delete the specified configuration element in the target configuration. However, the NETCONF server behaves differently for each attribute when the specified configuration element does not exist. If you use the remove attribute and the element does not exist, the server silently ignores the request. If you use the delete attribute and the element does not exist, the server returns an <rpc-error> element with an <error-tag> value of data-missing. We recommend that you use the remove attribute when you want to delete an element but are unsure if the element exists.
To represent each configuration element being deleted (either within the <config> tag element or in the file named by the <url> tag element), the application emits the tag elements representing its parent hierarchy levels, as described in Change Individual Configuration Elements Using NETCONF. The placement of the operation="delete" attribute or operation="remove" attribute depends on the element type, as described in the following sections.
Deleting a Hierarchy Level or Container Object
To delete a hierarchy level and all of its children (or a container object that has
children but no identifier), a client application
includes the operation="delete"
attribute or the
operation="remove" attribute in
the empty tag that represents the
level.
<configuration> <!-- opening tags for each parent level --> <level-to-delete operation="(delete | remove)"/> <!-- closing tags for each parent level --> </configuration>
We recommend that the application
set the default mode to no-change by including the
<default-operation> tag
element with the value none, as
described in Set the Edit Configuration Mode in a NETCONF Session. For more information about hierarchy levels
and container objects, see Map Configuration Statements to Junos XML Tag Elements.
The following example shows how to
remove the [edit protocols ospf]
hierarchy level of the candidate
configuration:
Deleting a Configuration Object That Has an Identifier
To delete a configuration object that has an identifier, a client application includes
the operation="delete" attribute
or the operation="remove"
attribute in the container tag element for the
object. Inside the container tag element, it
includes the identifier tag element only, not any
tag elements that represent other characteristics.
In the following, the identifier tag element is
called <name>:
<configuration> <!-- opening tags for each parent of the object --> <object operation="(delete | remove)"> <name>identifier</name> </object> <!-- closing tags for each parent of the object --> </configuration>
The delete or
remove attribute appears in the
opening container tag, not in the identifier tag
element. You include the identifier tag element to
delete the specified object, not the entire
hierarchy level represented by the container
tag.
We recommend that the application set
the default mode to no-change by including the
<default-operation> tag
element with the value none, as
described in Set the Edit Configuration Mode in a NETCONF Session. For more information about identifiers, see
Map Configuration Statements to Junos XML Tag Elements.
The following example shows how to
remove the user object barbara
from the [edit system login user]
hierarchy level in the candidate
configuration:
Deleting a Single-Value or Fixed-Form Option from a Configuration Object
To delete either a fixed-form option or an option that takes just one value from a
configuration object, a client application
includes the operation="delete"
attribute or the
operation="remove" attribute in
the tag element for the option. In the following
example, the identifier tag element for the object
is called <name>. (For
information about deleting an option that can take
multiple values, see Deleting Values from a Multi-value Option of a Configuration Object.)
<configuration> <!-- opening tags for each parent of the object --> <object> <name>identifier</name> <!-- if object has an identifier --> <option1 operation="(delete | remove)"> <option2 operation="(delete | remove)"> <!-- tag elements for other options to delete --> </object> <!-- closing tags for each parent of the object --> </configuration>
We recommend that the application
set the default mode to no-change by including the
<default-operation> tag
element with the value none, as
described in Set the Edit Configuration Mode in a NETCONF Session. For more information about options, see Map Configuration Statements to Junos XML Tag Elements.
The following example shows how to
remove the fixed-form option
disable at the
[edit forwarding-options sampling]
hierarchy level:
Deleting Values from a Multi-value Option of a Configuration Object
As described in Map Configuration Statements to Junos XML Tag Elements, some Junos OS configuration objects are leaf statements that have multiple values. In the formatted ASCII CLI representation, the values are enclosed in square brackets following the name of the object:
object [value1 value2 value3 ...];
The Junos XML representation does
not use a parent tag for the object, but instead
uses a separate instance of the object tag element
for each value. In the following example, the
identifier tag element is called
<name>:
<parent-object> <name>identifier</name> <object>value1</object> <object>value2</object> <object>value3</object> </parent-object>
To remove one or more values for
such an object, a client application includes the
operation="delete" attribute or
the operation="remove" attribute
in the opening tag for each value. It does not
include tag elements that represent values to be
retained. In the following example, the identifier
tag element is called
<name>:
<configuration> <!-- opening tags for each parent of the parent object --> <parent-object> <name>identifier</name> <object operation="(delete | remove)">value1</object> <object operation="(delete | remove)">value2</object> </parent-object> <!-- closing tags for each parent of the parent object --> </configuration>
We recommend that the application
set the default mode to no-change by including the
<default-operation> tag
element with the value none, as
described in Set the Edit Configuration Mode in a NETCONF Session. For more information about leaf statements
with multiple values, see Map Configuration Statements to Junos XML Tag Elements.
The
following example shows how to remove two of the
permissions granted to the
user-accounts login
class:
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
<rpc-error> response is changed when <edit-config> uses the operation="delete" operation to delete a configuration element that is absent in the target configuration. The error severity is error instead of warning, and the <rpc-error> element includes the <error-tag>data-missing</error-tag> and <error-type>application</error-type> elements.