- play_arrow Overview
- play_arrow NETCONF XML Management Protocol Overview
- play_arrow NETCONF and Junos XML Tags Overview
- XML and Junos OS Overview
- XML Overview
- XML and NETCONF XML Management Protocol Conventions Overview
- Map Junos OS Commands and Command Output to Junos XML Tag Elements
- Map Configuration Statements to Junos XML Tag Elements
- Using NETCONF Configuration Response Tag Elements in NETCONF Requests and Configuration Changes
-
- play_arrow Manage NETCONF Sessions
- play_arrow NETCONF Session Overview
- play_arrow Manage NETCONF Sessions
- Establish an SSH Connection for a NETCONF Session
- NETCONF Sessions over Transport Layer Security (TLS)
- NETCONF and Shell Sessions over Enhanced Outbound HTTPS
- NETCONF Sessions over Outbound HTTPS
- NETCONF Call Home Sessions
- NETCONF Sessions
- Sample NETCONF Session
- How Character Encoding Works on Juniper Networks Devices
- Configure RFC-Compliant NETCONF Sessions
- NETCONF Monitoring
- NETCONF Event Notifications
- play_arrow NETCONF Tracing Operations
- play_arrow NETCONF Protocol Operations and Attributes
- play_arrow NETCONF Request and Response Tags
- play_arrow Junos XML Protocol Elements Supported in NETCONF Sessions
- <abort/>
- <abort-acknowledgement/>
- <checksum-information>
- <close-configuration/>
- <commit-configuration>
- <commit-results>
- <commit-revision-information>
- <database-status>
- <database-status-information>
- <end-session/>
- <get-checksum-information>
- <get-configuration>
- <load-configuration>
- <load-configuration-results>
- <lock-configuration/>
- <open-configuration>
- <reason>
- <request-end-session/>
- <routing-engine>
- <unlock-configuration/>
- <xnm:error>
- <xnm:warning>
- play_arrow Junos XML Protocol Element Attributes Supported in NETCONF Sessions
-
- play_arrow Request Operational and Configuration Information Using NETCONF
- play_arrow Request Operational Information Using NETCONF
- play_arrow Request Configuration Information Using NETCONF
- Request the Committed Configuration and Device State Using NETCONF
- Request Configuration Data Using NETCONF
- Specify the Source for Configuration Information Requests Using NETCONF
- Specify the Scope of Configuration Information to Return in a NETCONF Response
- Request the Complete Configuration Using NETCONF
- Request a Configuration Hierarchy Level or Container Object Without an Identifier Using NETCONF
- Request All Configuration Objects of a Specified Type Using NETCONF
- Request Identifiers for Configuration Objects of a Specified Type Using NETCONF
- Request A Specific Configuration Object Using NETCONF
- Request Specific Child Tags for a Configuration Object Using NETCONF
- Request Multiple Configuration Elements Simultaneously Using NETCONF
- Retrieve a Previous (Rollback) Configuration Using NETCONF
- Compare Two Previous (Rollback) Configurations Using NETCONF
- Retrieve the Rescue Configuration Using NETCONF
- Request an XML Schema for the Configuration Hierarchy Using NETCONF
-
- play_arrow NETCONF Utilities
- play_arrow NETCONF Perl Client
- play_arrow Develop NETCONF Perl Client Applications
- Write NETCONF Perl Client Applications
- Import Perl Modules and Declare Constants in NETCONF Perl Client Applications
- Connect to the NETCONF Server in Perl Client Applications
- Collect Parameters Interactively in NETCONF Perl Client Applications
- Submit a Request to the NETCONF Server in Perl Client Applications
- Example: Request an Inventory of Hardware Components Using a NETCONF Perl Client Application
- Example: Change the Configuration Using a NETCONF Perl Client Application
- Parse the NETCONF Server Response in Perl Client Applications
- Close the Connection to the NETCONF Server in Perl Client Applications
-
- play_arrow YANG
- play_arrow YANG Overview
- Understanding YANG on Devices Running Junos OS
- Understanding Junos YANG Modules
- YANG Modules Overview
- Understanding the YANG Modules That Define the Junos OS Configuration
- Understanding the YANG Modules for Junos Operational Commands
- Junos Genstate YANG Data Models
- Understanding the Junos DDL Extensions YANG Module
- YANG Metadata Annotations for Junos Devices
- Use Juniper Networks YANG Modules
- play_arrow Create and Use Non-Native YANG Modules
- Understanding the Management of Nonnative YANG Modules on Devices Running Junos OS
- Manage YANG Packages, Modules, and Scripts on Junos Devices
- Managing YANG Packages and Configurations During a Software Upgrade or Downgrade
- Create Translation Scripts for YANG Configuration Models
- Disable and Enable YANG Translation Scripts on Devices Running Junos OS
- Commit and Display Configuration Data for Nonnative YANG Modules
- Create Custom RPCs in YANG for Devices Running Junos OS
- Create Action Scripts for YANG RPCs on Junos Devices
- Use Custom YANG RPCs on Devices Running Junos OS
- Example: Use a Custom YANG RPC to Retrieve Operational Information on Junos Devices
- Understanding Junos OS YANG Extensions for Formatting RPC Output
- Customize YANG RPC Output on Devices Running Junos OS
- Define Different Levels of Output in Custom YANG RPCs for Junos Devices
- Display Valid Command Option and Configuration Statement Values in the CLI for Custom YANG Modules
- Configure a NETCONF Proxy Telemetry Sensor in Junos
-
- play_arrow OpenDaylight Integration
- play_arrow Configure OpenDaylight Integration
-
- play_arrow Configuration Statements and Operational Commands
Set the Edit Configuration Mode in a NETCONF Session
When sending configuration data to the NETCONF server, you can specify how the device should handle the configuration changes. This is known as the edit configuration mode. You can set the edit configuration mode globally for the entire session. You can also set the edit mode for only specific elements within the session.
Devices running Junos OS have the following edit configuration modes:
merge
—The device merges new configuration data into the existing configuration data. This is the default.replace
—The device replaces existing configuration data with the new configuration data.none
—The device does not change the existing configuration unless the new configuration element includes an operation attribute.
To set the edit configuration mode globally for the session,
include the <default-operation>
element
with the desired mode as a child element of <edit-config>
.
<rpc> <edit-config> <default-operation>mode</default-operation> <edit-config> </rpc>
To specify the edit configuration mode for an individual
element, include the operation
attribute
and desired mode in that element’s tag.
<rpc> <edit-config> <config> <configuration> <protocols> <rip> <message-size operation="replace">255</message-size> </rip> </protocols> </configuration> </config> </edit-config> </rpc>
You can also set a global edit configuration mode for an entire set of configuration changes and specify a different mode for individual elements that you want handled in a different manner. For example:
<rpc> <edit-config> <default-operation>merge</default-operation> <config> <configuration> <protocols> <rip> <message-size operation="replace">255</message-size> </rip> </protocols> </configuration> </config> </edit-config> </rpc>
The edit configuration modes are discussed in more detail in the following sections:
Specifying the merge Data Mode
By default, the NETCONF server merges new configuration data into the candidate configuration or open configuration database. Thus, if you do not specify an edit configuration mode, the device merges the new configuration elements into the existing configuration.
Merging configurations is performed according to the following rules. (The rules also apply when updating configuration data in an open configuration database, for example, the ephemeral database, 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 configuration but not in the new configuration remains unchanged.
A configuration element that exists in the new configuration but not in the candidate configuration is added to the candidate configuration.
If a configuration element exists in both configurations, the following results occur:
If a child statement of the configuration element (represented by a child tag element) exists in the candidate configuration but not in the new configuration, it remains unchanged.
If a child statement exists in the new configuration but not in the candidate, it is added to the candidate configuration.
If a child statement exists in both configurations, the value in the new data replaces the value in the candidate configuration.
To explicitly specify that data be merged, the application includes
the <default-operation>
tag element
with the value merge
in the <edit-config>
tag element.
<rpc> <edit-config> <default-operation>merge</default-operation> <!-- other child tag elements of the <edit-config> tag element --> </edit-config> </rpc> ]]>]]>
Specifying the replace Data Mode
In the replace edit configuration mode,
the new configuration data completely replaces the data in the candidate
configuration or open configuration database. To specify that the
data be replaced, the application includes the <default-operation>
tag element with the value replace
in
the <edit-config>
tag element.
<rpc> <edit-config> <default-operation>replace</default-operation> </edit-config> </rpc> ]]>]]>
We recommend using the global replace mode only when you plan
to completely overwrite the existing configuration with new configuration
data. Furthermore, when the edit configuration mode is set to replace
, we do not recommend using the operation
attribute for individual configuration elements.
You can also replace individual configuration elements while merging or creating others. See Replace Configuration Elements Using NETCONF.
Specifying the none (no-change) Data Mode
In the none
(no-change) edit configuration mode, changes to the configuration are ignored.
This mode is useful when you are deleting elements, and it prevents
the NETCONF server from creating parent hierarchy levels for an element
that is being deleted. For more information, see Delete Configuration Elements Using NETCONF.
To set the no-change edit configuration mode globally,
the application includes the <default-operation>
tag element with the value none
in the <edit-config>
tag element.
<rpc> <edit-config> <default-operation>none</default-operation> </edit-config> </rpc>
If the new configuration data includes a configuration
element that is not in the existing configuration, the NETCONF server
returns an error. We recommend using mode none
only when removing configuration elements from the configuration.
When creating or modifying elements, applications must use merge mode.
When you use the <default-operation>
tag to globally set the edit configuration mode to none
to indicate the no-change mode, you can still
override this mode and specify a different edit configuration mode
for individual elements by including the operation
attribute in the element’s tag. For example:
<rpc> <edit-config> <default-operation>none</default-operation> <config> <configuration> <system> <services> <outbound-ssh> <client> <name>test</name> <device-id>test</device-id> <keep-alive> <retry operation="merge">4</retry> <timeout operation="merge">15</timeout> </keep-alive> </client> </outbound-ssh> </services> </system> </configuration> </config> </edit-config> </rpc>
Change History Table
Feature support is determined by the platform and release you are using. Use Feature Explorer to determine if a feature is supported on your platform.
<default-operation>
to replace
, the device
uses a load update
operation instead of a load override
operation to replace the configuration. In load update operations, the device notifies
only the Junos processes that correspond to changed statements, thus minimizing possible
disruptions to the network.