Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

close
keyboard_arrow_left
list Table of Contents
file_download PDF
{ "lLangCode": "en", "lName": "English", "lCountryCode": "us", "transcode": "en_US" }
English
keyboard_arrow_right

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

date_range 19-May-22

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>:

content_copy zoom_out_map
<configuration>
    <!-- opening tag for each parent of the element -->
        <element inactive="inactive"> 
            <name>identifier</name> <!-- if element has an identifier -->
            <!-- tag elements for each child of the element -->
        </element> 
    <!-- closing tag for each parent of the element -->
</configuration>
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.

content_copy zoom_out_map
<configuration-text>
/* statements for parent levels */
    
    /* For an object with an identifier */
        inactive: 
        object identifier {
             /* Child configuration statements */
        }
    
    /* For a hierarchy level or object without an identifier */
        inactive: 
        element {
            /* Child configuration statements */
        }
    
/* closing braces for parent levels */
</configuration-text>

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.

content_copy zoom_out_map
<configuration-set>
    set statement-path-to-object object identifier 
    deactivate statement-path-to-object object identifier 
</configuration-set>

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.

content_copy zoom_out_map
<configuration-json>
{
    "configuration" : {
        /* JSON objects for parent levels */
            "level-or-container" : {
                "@" : {
                    "comment" : "/* deactivate a hierarchy */",
                    "inactive" : true
                },
                "object" : [
                {
                    "@" : {
                        "comment" : "/* deactivate an object with an identifier */",
                        "inactive" : true
                    },
                    "name" : "identifier",    
                    "statement-name" : "statement-value", 
                    "@statement-name" : {
                        "comment" : "/* deactivate a statement */",
                        "inactive" : true
                    },
                    /* additional data and child objects */  # if any
                }
                ]
            }
        /* closing braces for parent levels */
    }
}
</configuration-json>
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:

content_copy zoom_out_map
<configuration>
    <!-- opening tag for each parent of the element -->
        <!- - For an object with an identifier -->
        <object ( inactive="inactive" | active="active" ) > 
            <name>identifier</name> 
        </object> 
    
        <!-- For a hierarchy level or object without an identifier -->
        <level-or-container ( inactive="inactive" | active="active" ) />
    <!-- closing tag for each parent of the element -->
</configuration>
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):

content_copy zoom_out_map
<configuration-text>
/* statements for parent levels */
    
    /* For an object with an identifier */
        (inactive | active): 
        object identifier; 
    
    /* For a hierarchy level or object without an identifier */
        (inactive | active): 
        object-or-level; 
        
/* closing braces for parent levels */
</configuration-text>

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.

content_copy zoom_out_map
<configuration-set>
    /* For an object with an identifier */
    activate statement-path-to-object object identifier
    deactivate statement-path-to-object object identifier
    
    /* For a hierarchy level or object without an identifier */
    activate statement-path-to-object-or-level object-or-level
    deactivate statement-path-to-object-or-level object-or-level
</configuration-set>

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.

content_copy zoom_out_map
<configuration-json>
{
    "configuration" : {
        /* JSON objects for parent levels */
            "level-or-container" : {
                "@" : {
                    "comment" : "/* activate or deactivate a hierarchy */",
                    "(active | inactive)" : true
                },
                "object" : [
                {
                    "@" : {
                        "comment" : "/* activate or deactivate an object with an identifier */",
                        "(active | inactive)" : true
                    },
                    "name" : "identifier",
                    "@statement-name" : {
                        "comment" : "/* activate or deactivate a statement */",
                        "(active | inactive)" : true
                    }               
                }
                ]
            }
        /* closing braces for parent levels */
    }
}
</configuration-json>
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.

content_copy zoom_out_map
<rpc>
<load-configuration format="json">
<configuration-json>
{
   "configuration" : {
      "protocols" : {
         "isis" : {
            "@" : {
               "inactive" : true
            }
         }
      }
   }
}
</configuration-json>
</load-configuration>
</rpc>
external-footer-nav