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 CDP Data Model
Cisco Discovery Protocol (CDP) configuration has an inherent augmented model (interface-configuration). The augmentation indicates that CDP can be configured at both the global configuration level and the interface configuration level. The data model for CDP interface manager in tree structure is:
module: Cisco-IOS-XR-cdp-cfg
+--rw cdp
+--rw timer? uint32
+--rw advertise-v1-only? empty
+--rw enable? boolean
+--rw hold-time? uint32
+--rw log-adjacency? empty
augment /a1:interface-configurations/a1:interface-configuration:
+--rw cdp
+--rw enable? empty
augment "/a1:interface-configurations/a1:interface-configuration" {
container cdp {
description "Interface specific CDP configuration";
leaf enable {
type empty;
description "Enable or disable CDP on an interface";
}
}
description
"This augment extends the configuration data of
'Cisco-IOS-XR-ifmgr-cfg'";
}
CDP Operational YANG:
module: Cisco-IOS-XR-cdp-oper
+--ro cdp
+--ro nodes
+--ro node* [node-name]
+--ro neighbors
| +--ro details
| | +--ro detail*
| | +--ro interface-name? xr:Interface-name
| | +--ro device-id? string
| | +--ro cdp-neighbor*
| | +--ro detail
| | | +--ro network-addresses
| | | | +--ro cdp-addr-entry*
| | | | +--ro address
| | | | +--ro address-type? Cdp-l3-addr-protocol
| | | | +--ro ipv4-address? inet:ipv4-address
| | | | +--ro ipv6-address? In6-addr
| | | +--ro protocol-hello-list
| | | | +--ro cdp-prot-hello-entry*
| | | | +--ro hello-message? yang:hex-string
| | | +--ro version? string
| | | +--ro vtp-domain? string
| | | +--ro native-vlan? uint32
| | | +--ro duplex? Cdp-duplex
| | | +--ro system-name? string
| | +--ro receiving-interface-name? xr:Interface-name
| | +--ro device-id? string
| | +--ro port-id? string
| | +--ro header-version? uint8
| | +--ro hold-time? uint16
| | +--ro capabilities? string
| | +--ro platform? string
.......................... (snipped) ...........................
Feedback