Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Change a Configuration Element’s Activation State Using the Junos XML Protocol

When a configuration element (hierarchy level or configuration object) is deactivated and the configuration is committed, the deactivated element remains in the configuration, but the element does not affect the functioning of the device. Deactivating configuration elements is useful when you want to troubleshoot issues by suppressing the behavior of a configuration element without deleting it from the configuration. Additionally, you can configure and deactivate new configuration elements to prepare the configuration to accommodate new hardware before it is available.

In a NETCONF or Junos XML protocol session with a Junos device, a client application can deactivate an existing element or simultaneously create and deactivate a new element. A client application can also activate a deactivated element so that when the configuration is committed, the element again has an effect on the functioning of the device. The following sections discuss how to create and deactivate new configuration elements and how to activate or deactivate existing elements:

Deactivating a Newly Created Element

To create an element and immediately deactivate it, a client application first includes the basic tag elements or configuration statements for the new element and any child elements as described in Creating, Modifying, or Deleting Configuration Elements Using the Junos XML Protocol.

XML

When using Junos XML tag elements to create and deactivate a new element, the application includes the inactive="inactive" attribute in the opening tag for the new element. In the following example, the identifier tag element is called <name>:

Note:

In a YANG-compliant NETCONF session, you can activate or deactivate a configuration element in XML data by including the xmlns:jcmd="http://yang.juniper.net/junos/jcmd" and jcmd:active="(true | false)" attributes in the tag element. For more information, see YANG Metadata Annotations for Junos Devices.

Text

When using formatted ASCII text to create and deactivate a new element, the application precedes the new element with the inactive: operator.

Configuration Mode (Set) Commands

When using configuration mode commands to create an inactive element, the application first creates the element with the set command and then deactivates it by using the deactivate command.

JSON

When using JSON configuration data to create and deactivate a new element, the client application includes the "inactive" : true attribute in the attribute list for that element. The following generic JSON configuration indicates the placement of the attribute for deactivating a hierarchy or container object, an object that has an identifier, and a leaf statement.

Note:

In a YANG-compliant NETCONF session, you can activate or deactivate a configuration object in JSON data by including the "junos-configuration-metadata:active" : (true | false) annotation in the statement's metdata object. For more information, see YANG Metadata Annotations for Junos Devices.

Deactivating or Reactivating an Existing Element

To deactivate an existing element, or activate a previously deactivated element, a client application includes the basic tag elements or configuration statements for its parent levels, as described in Creating, Modifying, or Deleting Configuration Elements Using the Junos XML Protocol.

XML

When using Junos XML tag elements to represent a configuration object that has an identifier, the application includes the inactive="inactive" or active="active" attribute in the object’s opening container tag and also emits the identifier tag element and value. In the following example, the identifier tag element is called <name>. To represent a hierarchy level or container object that has children but does not have an identifier, the application uses an empty tag:

Note:

In a YANG-compliant NETCONF session, you can activate or deactivate a configuration element in XML data by including the xmlns:jcmd="http://yang.juniper.net/junos/jcmd" and jcmd:active="(true | false)" attributes in the tag element. For more information, see YANG Metadata Annotations for Junos Devices.

Text

When using formatted ASCII text to represent the element, the application precedes the element with the inactive: or active: operator. The name of a hierarchy level or container object is followed by a semicolon (even though in the existing configuration it is followed by curly braces that enclose its child statements):

Configuration Mode (Set) Commands

When using configuration mode commands to activate or deactivate an object, the application specifies the activate or deactivate command equivalent to the CLI configuration mode command.

JSON

When using JSON to represent the element, the client application activates or deactivates the element by including the "active" : true or "inactive" : true attribute, respectively, in the attribute list of that element. The following generic JSON configuration indicates the placement of the attribute for activating or deactivating existing hierarchies or container objects, objects that have an identifier, and leaf statements.

Note:

In a YANG-compliant NETCONF session, you can activate or deactivate a configuration object in JSON data by including the "junos-configuration-metadata:active" : (true | false) annotation in the statement's metadata object. For more information, see YANG Metadata Annotations for Junos Devices.

The following example shows how to deactivate the isis hierarchy level at the [edit protocols] hierarchy level in the candidate configuration using Junos XML tag elements.

The following example shows how to deactivate the isis hierarchy level at the [edit protocols] hierarchy level in the candidate configuration using JSON.