- 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 Manage Configurations Using NETCONF
- play_arrow Change the Configuration Using NETCONF
- Edit the Configuration Using NETCONF
- Upload and Format Configuration Data in a NETCONF Session
- Set the Edit Configuration Mode in a NETCONF Session
- Handle Errors While Editing the Candidate Configuration in a NETCONF Session
- Replace the Candidate Configuration Using NETCONF
- Roll Back Uncommitted Changes in the Candidate Configuration Using NETCONF
- Delete the Configuration Using NETCONF
- Change Individual Configuration Elements Using NETCONF
- Merge Configuration Elements Using NETCONF
- Create Configuration Elements Using NETCONF
- Delete Configuration Elements Using NETCONF
- Replace Configuration Elements Using NETCONF
- Replace Patterns in Configuration Data Using the NETCONF or Junos XML Protocol
- play_arrow Commit the Configuration Using NETCONF
- play_arrow Ephemeral Configuration Database
- Understanding the Ephemeral Configuration Database
- Unsupported Configuration Statements in the Ephemeral Configuration Database
- Enable and Configure Instances of the Ephemeral Configuration Database
- Commit and Synchronize Ephemeral Configuration Data Using the NETCONF or Junos XML Protocol
- Managing Ephemeral Configuration Database Space
- Example: Configure the Ephemeral Configuration Database Using NETCONF
-
- 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 OpenDaylight Integration
- play_arrow Configure OpenDaylight Integration
-
- play_arrow Configuration Statements and Operational Commands
Commit and Display Configuration Data for Nonnative YANG Modules
You can load standardized or custom YANG modules onto devices
running Junos OS to add data models that are not natively supported
by Junos OS but can be supported by translation. When you extend the
configuration hierarchy with new data models, you must also supply
one or more translation scripts that provide the translation logic
to map the nonnative configuration syntax to Junos OS. Translation
scripts are enabled by default as soon as you issue the request
system yang add
or request system yang update
command
to add them to the device.
You configure nonnative data models in the candidate configuration using the syntax defined for those models. When you configure statements that correspond to third-party YANG data models, for example, OpenConfig or custom YANG data models, the following features are not supported:
Using
configure batch
orconfigure private
modeConfiguring statements under the
[edit groups]
hierarchy
When you commit the configuration, the translation scripts translate the data for those models and commit the corresponding Junos OS configuration as a transient change in the checkout configuration.
Starting in Junos
OS Release 16.1R2, XPath expression evaluations for the following
YANG keywords are disabled by default during commit operations: leafref
, must
, and when
. Prior to Junos OS Release 16.1R2, Junos OS evaluates
the constraints for these keywords, which can result in longer commit
times.
The candidate and active configurations contain the configuration
data for nonnative YANG data models in the syntax defined by those
models. However, because the translated configuration data is committed
as a transient change, the candidate and active configurations do
not explicitly display the translated data in the Junos OS syntax
when you view the configuration by using commands such as show
or show configuration
.
You can explicitly display the translated data in Junos OS syntax
in the candidate or active configuration by appending the | display
translation-scripts
filter to the show
command in
configuration mode or the show configuration
command in
operational mode. Applying the filter displays the post-inheritance
configuration with the translated configuration data from all enabled
translation scripts included.
You can only apply the | display translation-scripts
filter to the complete Junos OS configuration. You cannot filter
subsections of the configuration hierarchy.
In operational mode, issue the following command to view the committed configuration with translation scripts applied:
user@host> show configuration | display translation-scripts
Similarly, in configuration mode, issue the following command to view the candidate configuration with translation scripts applied:
[edit] user@host# show | display translation-scripts
The output, which is truncated in this example, displays the complete post-inheritance configuration and includes the nonnative configuration data as well as the translation of that data.
## Last changed: 2016-05-13 16:37:42 PDT version "16.1R1; system { host-name host; domain-name example.com; ... /* Translated data */ scripts { op { file test.slax; } } ... } ... /* Nonnative configuration data */ myconfig:myscript { op { filename test.slax; } }
Alternatively, you can view just the translated portions of
the hierarchy corresponding to nonnative YANG data models by appending
the translated-config
keyword to the | display
translation-scripts
filter. In operational mode, the translated-config
keyword returns the translated data for nonnative YANG data models
present in the committed configuration. In configuration mode, the translated-config
keyword returns the translated data for nonnative
YANG data models present in the candidate configuration, which includes
both committed and uncommitted configuration data.
user@host> show | display translation-scripts translated-config
system { scripts { op { file test.slax; } } }
The candidate configuration reflects the configuration data
that has been configured, but not necessarily committed, on the device.
In configuration mode, to display just the configuration differences
in the hierarchies corresponding to nonnative YANG data models before
or after translation scripts are applied, append the configured-delta
or translated-delta
keyword, respectively, to the show | display translation-scripts
command. In both cases,
the XML output displays the deleted configuration data, followed by
the new configuration data.
For example, to view the uncommitted configuration changes
for the nonnative data models in the syntax defined by those data
models, issue the show | display translation-scripts configured-delta
command in configuration mode.
[edit] user@host# show | display translation-scripts configured-delta
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/16.1R1/junos"> <configuration operation="delete"> </configuration> <configuration operation="create"> <myscript xmlns="http://jnpr.net/yang/myscript" operation="create"> <op> <filename>test2.slax</filename> </op> </myscript> </configuration> <cli> <banner>[edit]</banner> </cli> </rpc-reply>
To view the uncommitted configuration changes for the
nonnative data models after translation into Junos OS syntax, issue
the show | display translation-scripts translated-delta
command in configuration mode. For example:
[edit] user@host# show | display translation-scripts translated-delta
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/R1/junos"> <configuration xmlns:junos="http://xml.juniper.net/junos/*/junos"> <system> <scripts> <op> <file> <name>test2.slax</name> </file> </op> </scripts> </system> </configuration> <!-- EOF --> <cli> <banner>[edit]</banner> </cli> </rpc-reply>
In configuration mode, you can better understand the transient
changes that will be committed for the nonnative data models by using
the various filters. To verify all Junos OS statements that will be
committed as transient changes by translation scripts during the commit
operation, issue the show | display translation-scripts
translated-config
command before committing the candidate configuration.
To verify the Junos OS statements that will be committed for just
the changed configuration data, issue the show | display translation-scripts
translated-delta
command. If you disable translation scripts
for a package, the output for these commands does not include (and
the device does not commit) the corresponding Junos OS configuration
for those data models for which translation has been disabled.
Even though nonnative configuration data might be committed in the active configuration, it does not guarantee that the corresponding translated configuration is also committed as a transient change. If you disable translation and then commit nonnative configuration data, the nonnative data is present in the committed configuration. However, the device does not commit the corresponding Junos OS configuration statements as transient changes during the commit operation for any statements in the data models added by that package, even for those statements that were committed prior to disabling translation.
Table 1 summarizes the different filters you can apply to the committed and candidate configurations when they contain configuration data corresponding to nonnative YANG data models. The table indicates the CLI mode for each filter, and the scope and syntax of the output. By selecting different filters, you can view the entire configuration, the translated portions of the configuration, or the uncommitted configuration changes, and you can view the configuration data both before and after processing by translation scripts. In configuration mode, this enables you to better determine the Junos OS changes that will be committed for the nonnative hierarchies.
Filter | Mode | Description | Syntax and Format of Output |
---|---|---|---|
| Operational | Return the complete, post-inheritance committed configuration and include the translation of the nonnative data into Junos OS syntax. | YANG data model and Junos OS syntax as ASCII text |
Configuration | Return the complete, post-inheritance candidate configuration and include the translation of the nonnative data into Junos OS syntax. | YANG data model and Junos OS syntax as ASCII text | |
| Operational | Return the translated data corresponding to all nonnative YANG data models in the committed configuration. | Junos OS ASCII text |
Configuration | Return the translated data corresponding to all nonnative YANG data models in the candidate configuration. | Junos OS ASCII text | |
| Configuration | Return the uncommitted changes in the candidate configuration corresponding to nonnative YANG data models in the syntax defined by that model. | YANG data model XML |
| Configuration | Return the uncommitted changes in the candidate configuration corresponding to nonnative YANG data models after translation into Junos OS syntax. | Junos OS XML |
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.
leafref
, must
, and when
. Prior to Junos OS Release 16.1R2, Junos OS evaluates
the constraints for these keywords, which can result in longer commit
times.