Junos Genstate YANG Data Models
SUMMARY The Juniper Networks genstate YANG schema defines YANG data models for
operational state on Junos devices. gRPC Network Management Interface (gNMI) clients can
subscribe to the resource paths defined in the models to request state data.
Genstate YANG Data Models Overview
Starting in Junos OS Evolved Release 24.2R1, Juniper Networks publishes the genstate
YANG data models. The genstate models are subscribable YANG models for
operational state data on Junos devices. They are a YANG representation of operational
command output on Junos devices. The genstate models comprise a top-level
module augmented by modules for each of the different operational state areas as they are
published and made available. The genstate schema uses origin
'genstate'.
Junos devices have a rich set of native state data. You can retrieve operational state
information from Junos devices by executing operational commands or Junos XML RPCs on the
device. However, you must still parse the command output to extract specific data. Juniper
also provides the curated junos-state native YANG state models that
telemetry collectors can consume, but the models currently include only a subset of
operational areas and states.
The genstate YANG models expose state data available in operational show
commands through the gNMI subscribe RPC. The modules describe the resource paths that
relate to specific state data instances on the target network device. gNMI telemetry
collectors can subscribe to the corresponding resource path in the published YANG models to
query for the state data for that instance.
When you execute operational commands or RPCs on a Junos device, the device returns the XML
output enclosed in a top-level element. The root-level tag name describes the enclosed data.
For example, show interfaces commands return XML output that is enclosed in
an <interface-information> tag. The genstate modules
include the top-level XML tag name in the YANG module name and filename to easily identify
the data described in the module.
gNMI clients in gRPC dial-in environments can subscribe to the genstate
published paths. A client can use STREAM subscriptions in SAMPLE mode only to request the
data. ON_CHANGE mode is not supported. For information about using gNMI to subscribe to
telemetry data, see the Junos Telemetry Interface User Guide.
The genstate YANG data models are published and updated in different
releases. You can check the available models and supported paths for a given release in the
following ways:
-
View or download the modules from the Juniper/yang GitHub repository.
-
Download the modules from the Juniper Networks website at https://www.juniper.net/support/downloads.
Benefits of the Genstate YANG State Models
-
Increase the surface area of operational state available through gNMI and thus enable you to make more informed usage decisions about the device and network when you use gNMI to monitor state.
-
Simplify how you monitor device state by enabling you to move toward a single northbound interface.
Genstate Modules Overview
The genstate YANG data models comprise a top-level root module augmented
by modules for each of the available operational state areas. The genstate
schema uses origin 'genstate'.
The top-level module is as follows:
module junos-genstate {
namespace "http://yang.juniper.net/junos/genstate/";
prefix jgs;
organization
"Juniper Networks, Inc.";
contact
"Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA
+1 888 314-5822
E-mail: yang-support@juniper.net";
description
"This module contains a collection of top level nodes for JUNOS genstate data.
Copyright (c) 2023 Juniper Networks, Inc.
All rights reserved.";
revision 2023-01-01 {
description "Junos: ";
}
grouping genstate-top {
description "Top-level grouping for JUNOS genstate data";
container genstate {
description "Encapsulating top-level state container for all JUNOS genstate data";
config false;
}
}
uses genstate-top;
}
The top-level genstate module is augmented by the modules published for
each operational state area. When you issue operational commands or RPCs, the resulting XML
output defines a root tag that describes the operational area. The genstate
modules include this root tag name as part of the module name and filename to easily
identify the operational state area. The module prefix is based on the root tag name and so
varies for each module.
For example, the junos-genstate-interface-information module describes the
data that would normally be included in the <interface-information>
element in Junos command and RPC output. Thus, the model defines the resource paths that are
available for subscription by telemetry collectors for interface state data.
module junos-genstate-interface-information {
namespace "http://yang.juniper.net/junos/genstate/interface-information";
prefix jgii;
import junos-genstate {
prefix jgs;
revision-date 2023-01-01;
}
import junos-common-types {
prefix jt;
revision-date 2023-01-01;
}
organization
"Juniper Networks, Inc.";
contact
"Juniper Networks, Inc.
1133 Innovation Way
Sunnyvale, CA
+1 888 314-5822
E-mail: yang-support@juniper.net";
description "Junos genstate data model for interface-information";
revision 2023-01-01 {
description "Junos: ";
}
grouping interface-information-top {
description "Top-level grouping";
container interface-information {
config false;
description "Top-level container";
list physical-interface {
leaf name {
type string;
description "Name of this item";
}
leaf oper-status {
type string;
description "Current operational state of the interface";
}
leaf local-index {
type int32;
description "Local kernel index for this interface";
}
leaf snmp-index {
type int32;
description "SNMP ifIndex for this interface";
}
container if-config-flags {
leaf iff-none {
type empty;
}
leaf iff-hardware-down {
type empty;
}
leaf iff-down {
type empty;
}
leaf iff-up {
type empty;
}
leaf iff-admin-down {
type empty;
}
leaf iff-admin-up {
type empty;
}
leaf iff-link-down {
type empty;
}
leaf iff-device-down {
type empty;
}
leaf iff-point-to-point {
type empty;
}
leaf iff-point-to-multipoint {
type empty;
}
leaf plp-to-clp {
type empty;
}
leaf iff-multiaccess {
type empty;
}
leaf iff-snmp-traps {
type empty;
}
leaf iff-looped {
type empty;
}
leaf iff-framing-conflict {
type empty;
}
leaf internal-flags {
type string;
description "Hexadecimal value of internal flag bits";
}
}
list logical-interface {
leaf name {
type string;
description "Name of this item";
}
leaf local-index {
type int32;
description "Local kernel index for this interface";
}
leaf snmp-index {
type int32;
description "SNMP ifIndex for this interface";
}
leaf generation {
type string;
description "Generation number used to distinguish between successive instances of this interface";
}
leaf description {
type string;
description "Description of this interface";
}
leaf link-address {
type string;
description "Link address on this logical interface";
}
leaf encapsulation {
type string;
description "Encapsulation on the logical interface";
}
leaf subunit {
type int32;
description "Subunit for this interface";
}
container if-config-flags {
leaf iff-none {
type empty;
}
leaf iff-hardware-down {
type empty;
}
leaf iff-down {
type empty;
}
leaf iff-up {
type empty;
}
leaf iff-admin-down {
type empty;
}
leaf iff-admin-up {
type empty;
}
leaf iff-link-down {
type empty;
}
leaf iff-device-down {
type empty;
}
leaf iff-point-to-point {
type empty;
}
leaf iff-point-to-multipoint {
type empty;
}
leaf plp-to-clp {
type empty;
}
leaf iff-multiaccess {
type empty;
}
leaf iff-snmp-traps {
type empty;
}
leaf iff-looped {
type empty;
}
leaf iff-framing-conflict {
type empty;
}
leaf internal-flags {
type string;
description "Hexadecimal value of internal flag bits";
}
}
leaf admin-status {
type string;
description "Desired state of the interface";
}
leaf oper-status {
type string;
description "Current operational state of the interface";
}
}
}
}
}
augment "/jgs:genstate" {
description "Adds interface-information to top-level genstate";
uses interface-information-top;
}
}
A telemetry collector can subscribe to the different resource paths as defined in the
genstate models to query for state data. The genstate
model path syntax uses the origin genstate, includes a root tag named
genstate, and is followed by the top-level tag name for the operational
state area, for example, interface-information.
genstate:/genstate/interface-information/
For example, a gNMI client can use the following path to retrieve the administrative state of the et-1/0/1 interface:
genstate:/genstate/interface-information/physical-interface[name=et-1/0/1]/admin-status
Map Genstate Model Resource Paths to CLI Commands
You can use the show system data-models genstate operational command to
verify the CLI command that generates the output corresponding to a specific
genstate model resource path (Xpath expression). To retrieve the command,
include the xpath-cli-command-mapping option and provide the path to the
desired resource.
The following example retrieves the command that generates the state data corresponding to
the /genstate/system-information/os-version resource path.
user@host> show system data-models genstate xpath-cli-command-mapping /genstate/system-information/os-version Genstate xpath to CLI command mapping information (sometimes multiple commands might be mapped): > show system information
Similarly, the following example maps the
/genstate/interface-information/physical-interface[name=et-1/0/1]/admin-status
path to the CLI command that includes that information in the output.
user@host> show system data-models genstate xpath-cli-command-mapping /genstate/interface-information/physical-interface[name=et-1/0/1]/admin-status Genstate xpath to CLI command mapping information (sometimes multiple commands might be mapped): > show interfaces extensive