Changing a Configuration Element’s Activation State

When a configuration element (hierarchy level or configuration object) is deactivated, it remains in the candidate configuration or private copy, but when the configuration is later committed, the element does not affect the functioning of the routing platform. A client application can deactivate an element immediately as it creates it, or can deactivate an existing element. It can also reactivate an existing deactivated element so that when the configuration is committed, the element again has an effect on routing platform functioning.

See the following sections:

Deactivating a Newly Created Element

To define an element and immediately deactivate it, a client application includes the basic tag elements or configuration statements for its parent levels, as described in Creating, Modifying, or Deleting Configuration Elements.

If using Junos XML tag elements to define the new element, the application includes the inactive="inactive" attribute in the opening tag for the element. It includes tag elements for all children being defined for the element. In the following, the identifier tag element is called <name>:

<configuration>
    <!-- opening tag for each parent of the element -->
        <element inactive="inactive"> 
            <name>identifier</name> <!-- if the element has an identifier -->
            <!-- tag elements for each child of the element -->
        </element> 
    <!-- closing tag for each parent of the element -->
</configuration>

If using formatted ASCII text to define the new element, the application precedes the element with the inactive: operator. It includes all child statements that it is defining for all children of the element:

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

Deactivating or Reactivating an Existing Element

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

If 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, the identifier tag element is called <name>. To represent a hierarchy level or container object that has children but not an identifier, the application uses an empty tag:

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

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

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