Understanding Junos YANG Modules
Juniper Networks publishes the schema for Junos devices using YANG models for the configuration hierarchies, 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 and operational commands, as well as YANG extensions and types, for Junos devices. Starting in Junos OS Release 17.2, Junos YANG modules are specific to a device family. Table 1 outlines the identifiers for the different Junos device families and indicates which platforms are included in each family.
Device Family Identifier |
Supported Platforms |
---|---|
junos |
ACX Series, EX Series (certain platforms), MX Series, PTX Series |
junos-es |
J Series, LN Series, SRX Series |
junos-ex |
EX Series (certain platforms) |
junos-qfx |
QFX Series |
Different platforms within the same series might be categorized under different device
families. 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, and 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. In addition, the module filename 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.
Junos YANG Module |
Description |
Module Name |
Releases |
---|---|---|---|
Configuration modules |
Defines the schema for the Junos configuration hierarchy. Starting in Junos OS Release 17.4R1, the configuration YANG module is split into a root module that is augmented by multiple smaller modules. |
|
14.2 through 17.3 |
|
17.4R1 and later |
||
Operational command modules |
Represents 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 |
||
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 Downloading and Generating Junos YANG modules. For information about the module namespaces, see Understanding Junos YANG Module Namespaces and Prefixes.
Downloading and Generating Junos YANG modules
You can retrieve the Junos YANG modules by:
-
Downloading the modules from the Juniper Networks website at https://www.juniper.net/support/downloads
-
Downloading the modules from the Juniper Networks GitHub repository for YANG at https://github.com/Juniper/yang
-
Generating the modules on a Juniper Networks 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, including nodes both from native modules and from any standard or custom modules that have been 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 tar archive that is posted on the Juniper Networks website and that contains the YANG modules for a given release includes 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 |
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.
Common modules use the module name differentiator as an identifier, for example
|
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 |
|
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> ]]>]]>
junos:command
extension
statement in schemas emitted with extensions.