- 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
Understanding Junos YANG Modules
Juniper Networks publishes the schema for Junos devices using YANG models for the configuration and operational state data, operational commands, and Junos extensions. The following sections discuss the native Junos YANG modules.
Junos YANG Modules Overview
Juniper Networks provides YANG modules that define the configuration hierarchies,
operational commands and state data, as well as YANG extensions and types, for devices
running Junos OS and devices running Junos OS Evolved. Starting in Junos OS Release 17.2,
the YANG modules are specific to a device family. Table 1 outlines the
identifiers for the different device families and indicates which platforms are included in
each family. Starting in Junos OS Evolved Release 23.4R2, all Junos OS Evolved platforms use
the junos
device family identifier.
Device Family Identifier | Junos OS Platforms | Junos OS Evolved Platforms |
---|---|---|
junos | ACX Series | ACX Series |
junos-es | J Series | – |
junos-ex | EX Series (certain platforms) | – |
junos-qfx | QFX Series | QFX Series (23.2 and earlier) |
Different platforms within the same series might be categorized under different device
families. On devices running Junos OS Evolved Release 23.4R1 and earlier and devices
running Junos OS, you can verify the family for a specific device by executing the
show system information
operational mode command or the
<get-system-information/>
RPC on the device. The value of the
Family
field in the command output or the
<os-name>
element in the RPC reply indicates the device
family.
Starting in Junos OS Release 17.4R1, the configuration YANG module is split into a root module that is augmented by multiple smaller modules. Additionally, the native Junos YANG modules use a new naming convention for the module's name, filename, and namespace. The module name and filename include the device family and the area of the configuration or command hierarchy to which the schema in the module belongs. The module filename also includes a revision date. Table 2 summarizes the YANG modules that are native to Junos devices and identifies the release in which the different module names are used.
Modules that do not require family-specific schemas and that are common to all platforms
use the junos
device family for the module's name, filename, and
namespace.
Junos YANG Module | Description | Module Name | Releases |
---|---|---|---|
Configuration modules | Define the schema for the Junos configuration hierarchy. Starting in Junos OS Release 17.4R1, the configuration YANG module is split into a root module (family-conf-root) that is augmented by multiple smaller modules. |
| 14.2 through 17.3 |
| 17.4R1 and later | ||
Operational command modules | Represent the operational command hierarchy and the collective group of modules that define the remote procedure calls (RPCs) for operational mode commands. There are separate modules for the different areas of the command hierarchy. |
| 16.1 through 17.3 |
| 17.4R1 and later | ||
junos-state state modules | Curated set of YANG modules for operational state data. | junos-state-area | 22.2R1 and later |
| Define YANG data models for operational state. The models expose a subset of show
command data through the gNMI |
| 24.2R1 and later (Junos OS Evolved) |
DDL extensions module | Contains Data Definition Language (DDL) statements for Junos devices. This module includes the |
| 15.1 through 17.3 |
| 17.4R1 and later | ||
ODL extensions module | Contains Output Definition Language (ODL) statements that can be used to create and customize formatted ASCII output for RPCs executed on Junos devices. |
| 16.1 through 17.3 |
| 17.4R1 and later | ||
Metadata annotations extensions module | Defines metadata annotations for configuration operations. Annotations are defined in RFC 7952, Defining and Using Metadata with YANG. | junos-configuration-metadata | 22.2R1 and later (Junos OS Evolved) |
Types module | Contains definitions for YANG types. |
| 17.4R1 and later |
To support YANG modules for different device families in different releases, the downloaded modules are organized by device family, and each module’s name, filename, and namespace reflects the device family to which the schema in the module belongs.
For information about obtaining the modules, see Download and Generate Junos YANG modules.
For information about the module namespaces, see Understanding Junos YANG Module Namespaces and Prefixes.
Download and Generate Junos YANG modules
You can retrieve the Junos OS and Junos OS Evolved YANG modules by:
Downloading the modules from the Juniper Networks website at https://www.juniper.net/support/downloads
Downloading the modules from the Juniper/yang GitHub repository
Generating the modules on a Juniper Networks device
Starting in Junos OS Evolved Release 23.4R1, we publish the Junos OS Evolved native Yang modules on the Juniper Networks download site and on GitHub. In earlier releases, you must generate the modules on the device.
In Junos OS Release 17.1 and earlier, the YANG modules for the Junos OS configuration and command hierarchies that are posted on the Juniper Networks website and in GitHub define the schema for all devices running that Junos OS release. By contrast, the YANG modules generated on the local device define the schema specific to that device. The device-specific schema includes nodes both from native modules and from any standard or custom modules that were added to the device.
Starting in Junos OS Release 17.2, Junos YANG modules are specific to a device family and each module’s namespace reflects the device family to which the schema in the module belongs. As a result, the download package and GitHub repository include a separate directory for each device family’s modules and a common directory for the modules that are common to all device families. Each family-specific directory uses its device family identifier as the directory name and contains the configuration and operational command modules that are supported on the platforms in that family. The device family identifiers are defined in Table 1. The YANG modules generated on a local device running Junos OS Release 17.2 still define the schema specific to that device.
Starting in Junos OS Release 17.4R1, the YANG modules generated on a local device, by
default, contain family-specific schemas, which are identical across all devices in the
given device family. To generate device-specific modules, configure the
device-specific
configuration statement at the [edit system
services netconf yang-modules]
hierarchy level.
Table 3 summarizes the scope of the schema in the downloaded and generated YANG modules for different Junos OS releases.
Junos OS Release | Scope of Schema in Downloaded Modules | Scope of Schema in Generated Modules |
---|---|---|
17.1 and earlier | All devices | Device |
17.2 through 17.3 | Device family | Device |
17.4R1 and later | Device family | Device family |
Starting in Junos OS Evolved Release 23.4R1, we publish the Junos OS Evolved YANG modules on the Juniper Networks download site and on GitHub. In earlier releases, you must generate the modules on the device.
Additionally, starting in Junos OS Release 23.4R1 and Junos OS Evolved Release 23.4R1, we provide all YANG data models for a given OS and release in a single download package and GitHub repository folder. The package and repository folder include:
Native configuration, state, and RPC data models
OpenConfig configuration and state models supported by that OS
IETF models supported by that OS
For more information about how to download or generate the Junos OS YANG modules, see Use Juniper Networks YANG Modules.
Understanding Junos YANG Module Namespaces and Prefixes
In Junos OS Release 17.1 and earlier, Junos YANG modules use a unique identifier to differentiate the namespace for each module.
namespace "http://yang.juniper.net/yang/1.1/module-id;
Starting in Junos OS Release 17.2R1, the Junos YANG modules are specific to a device family. To support distinct YANG modules for different device families in a given release, the YANG modules use a namespace that includes the module name, the device family, and the Junos OS release string, in addition to the identifier. For example:
namespace "http://yang.juniper.net/yang/1.1/module-id/module-name/device-family/release";
Starting in Junos OS Release 17.4R1, the namespace is simplified to include the device family, the module type, and an identifier that is unique to each module and that differentiates the namespace of the module from that of other modules.
namespace "http://yang.juniper.net/device-family/type/identifier";
The following definitions apply to all versions of the namespace in which that variable appears:
device-family | Identifier for the device family to which the schema in the module belongs, for
example, Modules with device-specific schemas and modules with family-specific schemas both use the same device family identifier in the namespace. Note: The common modules use the |
identifier | String that differentiates the namespace of the module from that of other modules. Junos configuration and command modules include an identifier that indicates the area
of the configuration or command hierarchy to which the schema in the module belongs.
|
module-id | Unique identifier specific to the module, for example, |
module-name | Name of the YANG module included in that file, for example,
|
release | Junos OS or Junos OS Evolved release in which the schema in that module is supported. |
type | Type of the module. Possible values include:
|
Table 4
outlines each module’s namespace URI and prefix (as defined by the module’s
prefix
statement) in the different releases. Starting in Junos OS Release
17.2, the prefix for each operational command module reflects the command hierarchy area of
the RPCs included in that module. Similarly, starting in Junos OS Release 17.4R1, the prefix
for each configuration YANG module reflects the configuration statement hierarchy that is
included in that module. The Junos YANG extension and type modules use the
junos
device family identifier in the namespace, but the modules are
common to all device families.
YANG Module | Release | Namespace URI | Prefix |
---|---|---|---|
Configuration modules | 17.1 and earlier | http://yang.juniper.net/yang/1.1/jc |
|
17.2 through 17.3 | http://yang.juniper.net/yang/1.1/jc/configuration/device-family/release |
| |
17.4R1 and later | http://yang.juniper.net/device-family/conf/hierarchy |
| |
Operational command modules | 17.1 and earlier | http://yang.juniper.net/yang/1.1/jrpc |
|
17.2 through 17.3 | http://yang.juniper.net/yang/1.1/jrpc/module-name/device-family/release | hierarchy | |
17.4R1 and later | http://yang.juniper.net/device-family/rpc/hierarchy | hierarchy | |
junos-state state modules | 22.2R1 and later | http://yang.juniper.net/junos/state/state-area | js-area |
| 24.2R1 and later |
|
|
DDL extensions module | 17.1 and earlier | http://yang.juniper.net/yang/1.1/je/ |
|
17.2 and later | http://yang.juniper.net/yang/1.1/je/junos-extension/junos/release |
| |
17.4R1 and later | http://yang.juniper.net/junos/common/ddl-extensions |
| |
ODL extensions module | 17.1 and earlier | http://yang.juniper.net/yang/1.1/jodl |
|
17.2 through 17.3 | http://yang.juniper.net/yang/1.1/jodl/junos-extension-odl/junos/release |
| |
17.4R1 and later | http://yang.juniper.net/junos/common/odl-extensions |
| |
Metadata annotations extensions module | 22.2R1 and later | http://yang.juniper.net/junos/jcmd | jcmd |
Types module | 17.4R1 and later | http://yang.juniper.net/junos/common/types |
|
Starting with Junos OS Release 17.2, when you configure the rfc-compliant
statement at the [edit system services netconf]
hierarchy level and request
configuration data in a NETCONF session, the server sets the default namespace for the
<configuration>
element to the same namespace as in the
corresponding YANG model. For example:
<rpc> <get-config> <source> <running/> </source> </get-config> </rpc> ]]>]]> <nc:rpc-reply xmlns:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/17.2R1/junos"> <nc:data> <configuration xmlns="http://yang.juniper.net/yang/1.1/jc/configuration/junos/17.2R1.13" junos:commit-seconds="1493761452" junos:commit-localtime="2017-05-02 14:44:12 PDT" junos:commit-user="user"> ... </configuration> </nc:data> </nc:rpc-reply> ]]>]]>
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.
junos
device family identifier instead of
junos-qfx
.junos:command
extension
statement in schemas emitted with extensions.