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>:
<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>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-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.
<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.
<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>
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:
<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>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-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.
<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.
<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>
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.
<rpc>
<load-configuration format="json">
<configuration-json>
{
"configuration" : {
"protocols" : {
"isis" : {
"@" : {
"inactive" : true
}
}
}
}
}
</configuration-json>
</load-configuration>
</rpc>