YANG Module
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.
-
Cisco-specific models: For a list of supported models and their representation, see Github.
-
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.
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. |
Example: Configuration YANG Model for AAA
(snippet)
module Cisco-IOS-XR-aaa-locald-cfg {
/*** NAMESPACE / PREFIX DEFINITION ***/
namespace "http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-locald-cfg";
prefix "aaa-locald-cfg";
/*** LINKAGE (IMPORTS / INCLUDES) ***/
import Cisco-IOS-XR-types { prefix "xr"; }
import Cisco-IOS-XR-aaa-lib-cfg { prefix "a1"; }
/*** META INFORMATION ***/
organization "Cisco Systems, Inc.";
.........................
......................... (truncated)Example: Operational YANG Model for AAA
(snippet)
module Cisco-IOS-XR-aaa-locald-oper {
/*** NAMESPACE / PREFIX DEFINITION ***/
namespace "http://cisco.com/ns/yang/Cisco-IOS-XR-aaa-locald-oper";
prefix "aaa-locald-oper";
/*** LINKAGE (IMPORTS / INCLUDES) ***/
import Cisco-IOS-XR-types { prefix "xr"; }
include Cisco-IOS-XR-aaa-locald-oper-sub1 {
revision-date 2015-01-07;
}
/*** META INFORMATION ***/
organization "Cisco Systems, Inc.";
........................
........................ (truncated)Note |
A module can include any number of sub-modules; each sub-module belongs to only one module. The names of all standard modules and sub-modules must be unique. |
Example: NETCONF Action for OSPFv3
(snippet)
clear ospfv3 1 vrf vrf1 statistics neighbor 2.2.2.2
RPC message based on the new ospfv3 yang model-
<rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<act-ospfv3-instance-vrf xmlns="http://cisco.com/ns/yang/Cisco-IOS-XR-ipv6-ospfv3-act">
<instance>
<instance-identifier>1</instance-identifier>
<vrf>
<vrf-name>vrf1</vrf-name>
<stats>
<neighbor>
<neighbor-id>2.2.2.2</neighbor-id>
</neighbor>
</stats>
</vrf>
</instance>
</act-ospfv3-instance-vrf>
</rpc>
Structure of YANG Models
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
Example: 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'";
}
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
............................................... (truncated)
Feedback