[Contents] [Prev] [Next] [Index] [Report an Error]

Merging Configuration Elements

By default, the JUNOScript server merges loaded configuration data into the candidate configuration according to the following rules. (The rules also apply to a private copy of the configuration, but for simplicity the following discussion refers to the candidate configuration only.)

A configuration element (hierarchy level or configuration object) that exists in the candidate but not in the loaded configuration remains unchanged.
A configuration element that exists in the loaded configuration but not in the candidate is added to the candidate.
If a configuration element exists in both configurations, the semantics are as follows:
- If a child statement of the configuration element (represented by a child tag element) exists in the candidate but not in the loaded configuration, it remains unchanged.
- If a child statement exists in the loaded configuration but not in the candidate, it is added to the candidate.
- If a child statement exists in both configurations, the value in the loaded configuration replaces the value in the candidate.

Merge mode is the default mode for new configuration elements, so the application simply emits the <load-configuration> tag element in an <rpc> tag element:



<rpc>
    <!- - For a file - ->
        
<load-configuration url="file" [format="text"]/>

    

<!- - For a data stream - ->
    
<load-configuration [format="text"]> 

        <!- - configuration data - ->
    
</load-configuration>

</rpc>

For more information about the url and format attributes, see Specifying the Source and Format of New Configuration Data.

To explicitly specify merge mode, the application can include the action="merge" attribute in the <load-configuration/> tag or opening <load-configuration> tag, as shown in the examples at the end of this section.

If using JUNOS XML tag elements to represent the element to merge into the configuration, the application includes the basic tag elements described in Creating, Modifying, or Deleting Configuration Elements. It does not include any attributes in the element’s container tag. If adding or changing the value of a child element, the application includes the tag elements for it. If a child remains unchanged, it does not need to be included in the loaded configuration. In the following, the identifier tag element is called <name>:



<configuration>
    <!- - opening tag for each parent of the element - ->
        
<container-tag> 

            
<name>identifier</name> <!- - if the element has an identifier - ->

            <!- - tag elements for other children, if any - ->

        
</container-tag> 

    <!- - closing tag for each parent of the element - ->
</configuration>

If using formatted ASCII text, the application includes the statement path described in Creating, Modifying, or Deleting Configuration Elements. It does not include a preceding operator, but does include the element’s identifier if it has one. If adding or changing the value of a child element, the application includes the tag elements for it. If a child remains unchanged, it does not need to be included in the loaded configuration.



<configuration-text>
/* statements for parent levels of the element */
    
element identifier  {

        
  /* child statements if any */

    
} 

/* closing braces for parent levels for the element */
</configuration-text>

The following example shows how to merge in a new interface called so-3/0/0 at the [edit interfaces] hierarchy level in the candidate configuration. The information is provided as JUNOS XML tag elements (the default).

The following example shows how to use formatted ASCII text to define the same new interface.

[Contents] [Prev] [Next] [Index] [Report an Error]