YANG Data Model
A YANG module defines a data model through the data of the router, and the hierarchical organization and constraints on that data. Each module is uniquely identified by a namespace URL. The YANG models describe the configuration and operational data, perform actions, remote procedure calls, and notifications for network devices.
The YANG models must be obtained from the router. The models define a valid structure for the data that is exchanged between the router and the client. The models are used by NETCONF and gRPC-enabled applications.
 Note |
gRPC is supported only in 64-bit platforms. |
-
Cisco-specific models: For a list of supported models and their representation, see Native models.
-
Common models: These models are industry-wide standard YANG models from standard bodies, such as IETF and IEEE. These models are also called Open Config (OC) models. Like synthesized models, the OC models have separate YANG models defined for configuration data and operational data, and actions.
All data models are stamped with semantic version 1.0.0 as baseline from release 7.0.1 and later.
For more details about YANG, refer RFC 6020 and 6087.
Components of a YANG Module
-
import imports external modules
-
include includes one or more sub-modules
-
augment provides augmentations to another module, and defines the placement of new nodes in the data model hierarchy
-
when defines conditions under which new nodes are valid
-
prefix references definitions in an imported module
The YANG models configure a feature, retrieve the operational state of the router, and perform actions.
Note |
The gRPC YANG path or JSON data is based on YANG module name and not YANG namespace. |
Structure of YANG Data Model
-
Configuration data: A set of writable data that is required to transform a system from an initial default state into its current state. For example, configuring entries of the IP routing tables, configuring the interface MTU to use a specific value, configuring an ethernet interface to run at a given speed, and so on.
-
Operational state data: A set of data that is obtained by the system at runtime and influences the behavior of the system in a manner similar to configuration data. However, in contrast to configuration data, operational state data is transient. The data is modified by interactions with internal components or other systems using specialized protocols. For example, entries obtained from routing protocols such as OSPF, attributes of the network interfaces, and so on.
-
Actions: A set of NETCONF actions that support robust network-wide configuration transactions. When a change is attempted that affects multiple devices, the NETCONF actions simplify the management of failure scenarios, resulting in the ability to have transactions that will dependably succeed or fail atomically.
For more information about Data Models, see RFC 6244.
YANG data models can be represented in a hierarchical, tree-based structure with nodes. This representation makes the models easy to understand.
Each feature has a defined YANG model, which is synthesized from schemas. A model in a tree format includes:
-
Top level nodes and their subtrees
-
Subtrees that augment nodes in other YANG models
-
Custom RPCs
-
leaf node - contains a single value of a specific type
-
leaf-list node - contains a sequence of leaf nodes
-
list node - contains a sequence of leaf-list entries, each of which is uniquely identified by one or more key leaves
-
container node - contains a grouping of related nodes that have only child nodes, which can be any of the four node types
Structure of LLDP Data Model
$ cat Cisco-IOS-XR-ethernet-lldp-cfg.yang
module Cisco-IOS-XR-ethernet-lldp-cfg {
/*** NAMESPACE / PREFIX DEFINITION ***/
namespace "http://cisco.com/ns"+
"/yang/Cisco-IOS-XR-ethernet-lldp-cfg";
prefix "ethernet-lldp-cfg";
/*** LINKAGE (IMPORTS / INCLUDES) ***/
import cisco-semver { prefix "semver"; }
import Cisco-IOS-XR-ifmgr-cfg { prefix "a1"; }
/*** META INFORMATION ***/
organization "Cisco Systems, Inc.";
contact
"Cisco Systems, Inc.
Customer Service
Postal: 170 West Tasman Drive
San Jose, CA 95134
Tel: +1 800 553-NETS
E-mail: cs-yang@cisco.com";
description
"This module contains a collection of YANG definitions
for Cisco IOS-XR ethernet-lldp package configuration.
This module contains definitions
for the following management objects:
lldp: Enable LLDP, or configure global LLDP subcommands
This YANG module augments the
Cisco-IOS-XR-ifmgr-cfg
module with configuration data.
Copyright (c) 2013-2019 by Cisco Systems, Inc.
All rights reserved.";
revision "2019-04-05" {
description
"Establish semantic version baseline.";
semver:module-version "1.0.0";
}
revision "2017-05-01" {
description
"Fixing backward compatibility error in module.";
}
revision "2015-11-09" {
description
"IOS XR 6.0 revision.";
}
container lldp {
description "Enable LLDP, or configure global LLDP subcommands";
container tlv-select {
presence "Indicates a tlv-select node is configured.";
description "Selection of LLDP TLVs to disable";
container system-name {
description "System Name TLV";
leaf disable {
type boolean;
default "false";
description "disable System Name TLV";
}
}
container port-description {
description "Port Description TLV";
leaf disable {
type boolean;
default "false";
description "disable Port Description TLV";
}
}
.......................... (snipped) ...........................
container management-address {
description "Management Address TLV";
leaf disable {
type boolean;
default "false";
description "disable Management Address TLV";
}
}
leaf tlv-select-enter {
type boolean;
mandatory true;
description "enter lldp tlv-select submode";
}
}
leaf holdtime {
type uint32 {
range "0..65535";
}
description
"Length of time (in sec) that receiver must
keep this packet";
.......................... (snipped) ...........................
}
augment "/a1:interface-configurations/a1:interface-configuration" {
container lldp {
presence "Indicates a lldp node is configured.";
description "Disable LLDP TX or RX";
.......................... (snipped) ...........................
description
"This augment extends the configuration data of
'Cisco-IOS-XR-ifmgr-cfg'";
}
}
The structure of a data model can be explored using a YANG validator tool such as pyang and the data model can be formatted in a tree structure.
LLDP Configuration Data Model
module: Cisco-IOS-XR-ethernet-lldp-cfg
+--rw lldp
+--rw tlv-select!
| +--rw system-name
| | +--rw disable? boolean
| +--rw port-description
| | +--rw disable? boolean
| +--rw system-description
| | +--rw disable? boolean
| +--rw system-capabilities
| | +--rw disable? boolean
| +--rw management-address
| | +--rw disable? boolean
| +--rw tlv-select-enter boolean
+--rw holdtime? uint32
+--rw enable-priority-addr? boolean
+--rw extended-show-width? boolean
+--rw enable-subintf? boolean
+--rw enable-mgmtintf? boolean
+--rw timer? uint32
+--rw reinit? uint32
+--rw enable? boolean
module: Cisco-IOS-XR-ifmgr-cfg
+--rw global-interface-configuration
| +--rw link-status? Link-status-enum
+--rw interface-configurations
+--rw interface-configuration* [active interface-name]
+--rw dampening
| +--rw args? enumeration
| +--rw half-life? uint32
| +--rw reuse-threshold? uint32
| +--rw suppress-threshold? uint32
| +--rw suppress-time? uint32
| +--rw restart-penalty? uint32
+--rw mtus
| +--rw mtu* [owner]
| +--rw owner xr:Cisco-ios-xr-string
| +--rw mtu uint32
+--rw encapsulation
| +--rw encapsulation? string
| +--rw capsulation-options? uint32
+--rw shutdown? empty
+--rw interface-virtual? empty
+--rw secondary-admin-state? Secondary-admin-state-enum
+--rw interface-mode-non-physical? Interface-mode-enum
+--rw bandwidth? uint32
+--rw link-status? empty
+--rw description? string
+--rw active Interface-active
+--rw interface-name xr:Interface-name
+--rw ethernet-lldp-cfg:lldp!
+--rw ethernet-lldp-cfg:transmit
| +--rw ethernet-lldp-cfg:disable? boolean
+--rw ethernet-lldp-cfg:receive
| +--rw ethernet-lldp-cfg:disable? boolean
+--rw ethernet-lldp-cfg:lldp-intf-enter boolean
+--rw ethernet-lldp-cfg:enable? Boolean
.......................... (snipped) ...........................LLDP Operational Data Model
$ pyang -f tree Cisco-IOS-XR-ethernet-lldp-oper.yang
module: Cisco-IOS-XR-ethernet-lldp-oper
+--ro lldp
+--ro global-lldp
| +--ro lldp-info
| +--ro chassis-id? string
| +--ro chassis-id-sub-type? uint8
| +--ro system-name? string
| +--ro timer? uint32
| +--ro hold-time? uint32
| +--ro re-init? uint32
+--ro nodes
+--ro node* [node-name]
+--ro neighbors
| +--ro devices
| | +--ro device*
.......................... (snipped) ...........................
notifications:
+---n lldp-event
+--ro global-lldp
| +--ro lldp-info
| +--ro chassis-id? string
| +--ro chassis-id-sub-type? uint8
| +--ro system-name? string
| +--ro timer? uint32
| +--ro hold-time? uint32
| +--ro re-init? uint32
+--ro nodes
+--ro node* [node-name]
+--ro neighbors
| +--ro devices
| | +--ro device*
| | +--ro device-id? string
| | +--ro interface-name? xr:Interface-name
| | +--ro lldp-neighbor*
| | +--ro detail
| | | +--ro network-addresses
| | | | +--ro lldp-addr-entry*
| | | | +--ro address
.......................... (snipped) ...........................
+--ro interfaces
| +--ro interface* [interface-name]
| +--ro interface-name xr:Interface-name
| +--ro local-network-addresses
| | +--ro lldp-addr-entry*
| | +--ro address
| | | +--ro address-type? Lldp-l3-addr-protocol
| | | +--ro ipv4-address? inet:ipv4-address
| | | +--ro ipv6-address? In6-addr
| | +--ro ma-subtype? uint8
| | +--ro if-num? uint32
| +--ro interface-name-xr? xr:Interface-name
| +--ro tx-enabled? uint8
| +--ro rx-enabled? uint8
| +--ro tx-state? string
| +--ro rx-state? string
| +--ro if-index? uint32
| +--ro port-id? string
| +--ro port-id-sub-type? uint8
| +--ro port-description? string
.......................... (snipped) ...........................
Feedback