Create, Modify, or Delete Configuration Elements Using the Junos XML Protocol
A Junos XML protocol client application can create, modify, and delete configuration elements on Junos devices using different formats.
A Junos XML protocol client application can create, modify, or delete one or more configuration elements (hierarchy levels and configuration objects) on devices running Junos OS or devices running Junos OS Evolved. A client application can change the configuration elements in the candidate configuration or an open configuration database. The application can load the changes as Junos XML elements, formatted ASCII text, configuration mode commands, or JavaScript Object Notation (JSON).
For more information about the source and formatting for configuration elements, see Upload and Format Configuration Data in a Junos XML Protocol Session.
For information about the operations a client application can perform on configuration elements, see the following sections:
-
Create New Elements in Configuration Data Using the Junos XML Protocol
-
Merge Elements in Configuration Data Using the Junos XML Protocol
-
Replace Elements in Configuration Data Using the Junos XML Protocol
-
Replace Only Updated Elements in Configuration Data Using the Junos XML Protocol
-
Delete Elements in Configuration Data Using the Junos XML Protocol
-
Rename Objects In Configuration Data Using the Junos XML Protocol
-
Reorder Elements In Configuration Data Using the Junos XML Protocol
-
Protect or Unprotect a Configuration Object Using the Junos XML Protocol
-
Change a Configuration Element’s Activation State Using the Junos XML Protocol
-
Replace Patterns in Configuration Data Using the NETCONF or Junos XML Protocol
The following sections provide an overview of how to create, modify, or delete configuration elements in the different formats.
Junos XML
To use Junos XML tag elements to represent an element, the application includes
the tag elements representing all levels in the configuration hierarchy from the
root (represented by the <configuration> element) down to
the element’s container tag element. The attributes and child tag elements that
are included depend on the operation being performed on the element. The syntax
applies both to the contents of a file and to a data stream. In the following
example, the identifier tag element is called <name>:
<configuration>
<!-- opening tag for each parent of the element -->
<container-tag [operation-attribute="value"]>
<name>identifier</name> <!-- if the element has an identifier -->
<!-- child tag elements --> <!-- if appropriate -->
</container-tag>
<!-- closing tag for each parent of the element -->
</configuration>Formatted ASCII Text
To use formatted ASCII text to represent an element, the application includes the
complete statement path, starting with a statement that can appear directly
under the [edit] hierarchy level. The attributes and child
statements to include depend on the operation being performed on the element.
The application encloses the set of statements in a
<configuration-text> element when it uploads the
configuration data as a data stream. The application omits the
<configuration-text> element when the configuration
data is stored in and loaded from a file.
<configuration-text>
/* statements for parent levels of the element */
operation-to-perform: # if appropriate
element identifier { # if the element has an identifier
/* child statements */ # if appropriate for the operation
}
/* closing braces for parent levels of the element */
</configuration-text>When loading formatted ASCII text, the application must include the
format="text" attribute in the
<load-configuration> tag.
Configuration Mode Commands
To use configuration mode commands to create, modify, or delete an element, the
application includes the commands as they would be typed in configuration mode
in the CLI. The device executes the configuration instructions line by line in
the order provided. You can specify the complete statement path in the command,
or you can use CLI navigation commands such as edit and
up, to move around the configuration hierarchy.
The application encloses the set of commands in a
<configuration-set> element when it uploads the
configuration data as a data stream. The application omits the
<configuration-set> element when the configuration
data is stored in and loaded from a file.
<configuration-set>
/* configuration mode commands */
</configuration-set>When loading configuration mode commands, the application must include the
action="set" and format="text" attributes
in the <load-configuration> tag.
JSON
To use JSON format to represent an element, the application includes JSON objects representing all levels in the configuration hierarchy from the root down to the JSON object representing that element. The attributes and child objects to include depend on the operation being performed on the element. If the attribute value is a Boolean data type, do not enclose the value in quotes.
The application encloses the JSON data in a
<configuration-json> element when it uploads the
configuration data as a data stream. The application omits the
<configuration-json> element when the configuration
data is stored in and loaded from a file.
<configuration-json>
{
"configuration" : {
/* JSON objects for parent levels of the element */
"container-tag" : {
"@" : {
"operation-attribute" : ( "value" | boolean )
},
"object" : [
{
"@" : {
"operation-attribute" : ( "value" | boolean )
},
"(name | element-identifier)" : "identifier",
"statement-name" : "statement-value",
"@statement-name" : {
"operation-attribute" : ( "value" | boolean )
},
/* additional JSON data and child objects */
}
]
}
/* closing braces for parent levels of the element */
}
}
</configuration-json>When loading data in JSON format, the application must include the
format="json" attribute in the
<load-configuration> tag.