Reorder Elements In Configuration Data Using the Junos XML Protocol
Junos XML protocol client applications can use the insert attribute
to reorder configuration objects that use an ordered set.
Junos devices store and display most configuration objects in predetermined positions in the configuration hierarchy. Thus, the order in which the system creates the object or its children is not significant. However, some configuration objects—such as routing policies and firewall filters—consist of elements that the system must process and analyze sequentially in order to produce the intended routing behavior. When a Junos XML protocol client application adds a new element to an ordered set, by default, the system appends the element to the existing list of elements. The client application can reorder the elements, if appropriate.
A Junos XML protocol client application can change the order of configuration
elements in an ordered set by including the insert attribute in the
request. A client application first includes the tag elements described in Create, Modify, or Delete Configuration Elements Using the Junos XML Protocol. When using Junos XML format, the application emits the tag or container tag that
represents the ordered set. The application also encloses the tag for each
identifier (if it has them). In the following examples, the identifier tag is
<name>.
To add or move an element to the first position in an ordered set, the application
includes the insert="first" attribute in the element's opening tag.
The following example inserts an object at the beginning of the ordered list defined
in the given leaf statement:
<configuration>
<!-- opening tag for each parent of the set -->
<ordered-set insert="first">identifier-for-moving-object</ordered-set>
<!-- closing tag for each parent of the set -->
</configuration>
The following example inserts the object identified by the
<name> element at the beginning of the list:
<configuration>
<!-- opening tag for each parent of the set -->
<ordered-set insert="first">
<name>identifier-for-moving-object</name>
</ordered-set>
<!-- closing tag for each parent of the set -->
</configuration>
A client application can also add or move an element to a position that is relative
to another element. The application includes the insert="before" or
insert="after" attribute in the opening tag to indicate the new
position of the moving element relative to another reference element in the set. To
identify the reference element, the application includes each of the reference
element’s identifiers as an attribute in the opening tag for the ordered set.
In the following example, the leaf statement contains an ordered list. The
application inserts the new list item before or after the item identified by the
name="referent-value" attribute.
<configuration>
<!-- opening tag for each parent of the set -->
<ordered-set insert="(before | after)" name="referent-value">identifier-for-moving-object</ordered-set>
<!-- closing tag for each parent of the set -->
</configuration>
In the following example, the elements in the set have one identifier called
<name>:
<configuration>
<!-- opening tag for each parent of the set -->
<ordered-set insert="(before | after)" name="referent-value">
<name>identifier-for-moving-object</name>
</ordered-set>
<!-- closing tag for each parent of the set -->
</configuration>
In the following example, each element in the set has two identifiers. The opening tag appears on two lines for legibility only.
<configuration>
<!-- opening tag for each parent of the set -->
<ordered-set insert="(before | after)" identifier1="referent-value"
identifier2="referent-value">
<identifier1>value-for-moving-object</identifier1>
<identifier2>value-for-moving-object</identifier2>
</ordered-set>
<!-- closing tag for each parent of the set -->
</configuration>When using configuration mode commands to reorder elements, the application specifies
the insert command that is equivalent to the CLI configuration mode
command.
<configuration-set>
insert statement-path-to-object identifier-for-moving-object (before | after) referent-value
</configuration-set> The insert="first" attribute has no equivalent CLI configuration
mode command.
The reordering operation does not support using formatted ASCII text or JSON to represent the configuration data.
The following example moves an existing firewall filter term called
default and places it after the filter
called rule1 in the firewall configuration for
filter1.
<rpc>
<load-configuration>
<configuration>
<firewall>
<family>
<inet>
<filter>
<name>filter1</name>
<term insert="after" name="rule1">
<name>default</name>
</term>
</filter>
</inet>
</family>
</firewall>
</configuration>
</load-configuration>
</rpc>
The following example performs the same operation as in the previous example but uses the equivalent configuration mode command:
<rpc>
<load-configuration action="set" format="text">
<configuration-set>
insert firewall family inet filter filter1 term default after term rule1
</configuration-set>
</load-configuration>
</rpc>In the following example, the BGP group my_group initially has an
export policy list with one export policy deny_all. The RPC inserts
a second export policy named my_export_policy before the
deny_all export policy.
<rpc>
<load-configuration>
<configuration>
<protocols>
<bgp>
<group>
<name>my_group</name>
<export insert="before" name="deny_all">my_export_policy</export>
</group>
</bgp>
</protocols>
</configuration>
</load-configuration>
</rpc>The following example moves an OSPF virtual link defined at the
[edit protocols ospf area area]
hierarchy level. The example moves the link with identifiers
neighbor-id 192.168.0.3 and
transit-area 10.10.10.1 before the link with identifiers
neighbor-id 192.168.0.5 and
transit-area 10.10.10.2. This operation is equivalent to the
following configuration mode command:
[edit protocols ospf area area] user@host# insert virtual-link neighbor-id 192.168.0.3 transit-area 10.10.10.1 before virtual-link neighbor-id 192.168.0.5 transit-area 10.10.10.2
Client Application
<rpc>
<load-configuration>
<configuration>
<protocols>
<ospf>
<area>
<name>area</name>
<virtual-link insert="before" neighbor-id="192.168.0.5" transit-area="10.10.10.2">
<neighbor-id>192.168.0.3</neighbor-id>
<transit-area>10.10.10.1</transit-area>
</virtual-link>
</area>
</ospf>
</protocols>
</configuration>
</load-configuration>
</rpc>