YANG data models

A YANG data model is a standardized network modeling language that

  • defines the structure and constraints for configuration and operational data on network devices,

  • enables automated setup and management of heterogeneous networks, and

  • supports communication using protocols such as NETCONF and gRPC for scalable, consistent network operations.

Model-driven programmability

Model-driven programmability uses YANG data models to provide a flexible, rich framework for device automation. This framework offers multiple ways to interface with Cisco IOS XR devices via different transports, protocols, and encodings, which are decoupled from the data models for greater flexibility.

Data model layers

YANG data models organize device functions and configurations into logical layers. For example, one layer may define device interfaces, while another handles routing protocols. This separation simplifies automation and standardizes management across device types.

Protocol operations

YANG data models work in conjunction with protocols such as Network Configuration Protocol (NETCONF) and gRPC. These protocols use YANG models to access device capabilities, automate configuration, and retrieve operational data across the network.

Benefits of YANG data models

Configuring routers with YANG data models overcomes traditional limitations because these models:

  • Provide a common structure for both configuration and operational data, and support NETCONF actions.

  • Enable protocols to get, manipulate, and delete network device configuration.

  • Automate management and operation of multiple routers throughout a heterogeneous network.

Additional information

Traditional CLI-based configuration is typically proprietary and highly text-based, making bulk configuration challenging in complex networks. By contrast, YANG data models use industry-standard languages to facilitate automation, interoperability, and operational consistency.

YANG data models

A YANG data model is a data modeling language specification that

  • defines a standard, hierarchical structure for the configuration and operational data of network devices

  • enables robust network communication by specifying data relationships, constraints, actions, and notifications, and

  • supports integration with network management protocols such as NETCONF and gRPC for automated configuration and monitoring.

  • YANG module: A file or group of files that together define a single data model. Each module is uniquely identified by a namespace URL.

  • NETCONF/gRPC: Protocols that use YANG data models for configuration and operational data exchange.

YANG data models must be obtained from the router. These models define a valid structure for the data exchanged between the router and the client, and are consumed by NETCONF and gRPC-enabled applications (gRPC supported only on 64-bit platforms). YANG models are categorized as follows:

  • Cisco-specific models: Proprietary YANG models unique to Cisco devices. For details and representation, see Native models.

  • Common models (Open Config/OC): Industry-standard YANG models, typically from organizations such as IETF and IEEE. OC models have separate YANG modules for configuration data, operational data, and actions. See OC models for examples.

All YANG data models are stamped with semantic version 1.0.0 as the baseline from release 7.0.1 and later. For more details on YANG, refer to RFC 6020 and RFC 6087.

YANG data model requirements

A YANG data model requirement is a specification that

  • defines the types of data a router must expose for configuration and monitoring

  • distinguishes between configuration data, operational state data, and supported actions, and

  • ensures network protocols can interact with routers in a consistent, standardized manner.

Types of YANG data model requirements

  • Configuration data: A set of writable data needed to transform a router from its initial state to an operational state (for example, entries in the IP routing table or interface MTU settings).

  • Operational state data: Data obtained at runtime that reflects the router’s current status. This data is typically transient and can change based on internal or external events (such as dynamic OSPF routing entries).

  • Actions: Transactions or commands, typically delivered via management protocols like NETCONF, that carry out configuration operations or queries, ensuring consistency and atomic changes across devices.

Key considerations for YANG data model requirements

  • YANG data model requirements are described in detail in RFC 6244.

  • Actions supported by YANG models enable reliable, network-wide configuration transactions.

  • Clear separation of configuration and operational data ensures effective management and simplifies troubleshooting.

YANG model structure

A YANG model structure is a hierarchical framework that

  • organizes data into a tree with top-level nodes and nested child nodes

  • groups related data through containers, lists, and leaves, and

  • enables clear representation, management, and extension of network configuration and state.

Hierarchical structure of YANG models

  • Top-level nodes and their subtrees: YANG models are organized with primary (top-level) nodes that represent major configuration or operational groupings. Each of these nodes may have nested subtrees covering related data elements or functions.

  • Subtrees that augment nodes in other YANG models: YANG allows modules to be extended by augmenting existing nodes, enabling models to add additional information or capabilities to base structures defined elsewhere.

  • Custom RPCs (Remote Procedure Calls): Beyond static configuration and state data, YANG models can define custom RPCs to perform operations or actions on managed devices, supporting automation and advanced control tasks.

YANG node types

A YANG node type is a structural element that

  • defines how data and groupings are represented in a YANG model

  • provides distinct roles, such as value holders or containers for related information, and

  • enables flexible modeling of configuration and operational data.

YANG node type definitions

  • Leaf node: Holds a single, typed value (for example, an integer, string, or IP address).

  • Leaf-list node: Contains a list of multiple leaf values, all of the same type (such as a series of IP addresses).

  • List node: Stores an ordered sequence of entries, each uniquely identified by one or more key leaves—for example, a set of interface configurations, where each entry represents a network interface.

  • Container node: Groups related nodes together (including any of the above node types) into a logical structure, such as general interface settings.


    Note

    Each node is named and either defines a value or contains child nodes according to its type.

Components of a YANG module

A YANG module component is a foundational element that

  • specifies how the module imports and references data from other modules

  • enables modular organization and extension through statements like include and augment, and

  • applies conditional logic and naming conventions for robust and maintainable models.

Statements for building YANG modules

  • Import statement: Incorporates definitions from external YANG modules, allowing reuse of established schemas.

  • Include statement: Pulls in sub-modules that contribute additional definitions or groupings to the main module.

  • Augment statement: Adds new nodes or definitions to an existing module or to specific locations within another module’s hierarchy.

  • When statement: Applies conditions, controlling whether a node is valid or included based on specific criteria.

  • Prefix statement: Assigns a shorthand reference to imported modules for clear, collision-free access to their definitions.


    Note

    The gRPC YANG path or JSON data is based on the YANG module name, not the namespace.

Additional reference information for YANG

  • All YANG data models from software release 7.0.1 and later are stamped with semantic version 1.0.0 by default.

  • YANG model requirements and practices are specified in industry standards such as RFC 6020, RFC 6087, and RFC 6244.

  • For open, industry-standard YANG models, see the OpenConfig public repository.

  • Tools like pyang can validate and visualize YANG models in tree format.

  • Cisco-specific YANG model documentation and downloadable model files can be accessed on the Cisco DevNet YANG Models page.

LLDP YANG data model

An LLDP YANG data model example is a representation that

  • illustrates how LLDP configuration and state information are organized using YANG’s hierarchical, tree-based structure

  • demonstrates the use of containers, lists, and leaf nodes for global settings and per-interface parameters, and

  • enables automated device discovery, neighbor identification, and protocol management via network tools.

Structure of LLDP data model

The Link Layer Discovery Protocol (LLDP) data model is represented in this structure:
$ 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

This example shows the LLDP interface manager configuration model in tree format.
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

This example shows the Link Layer Discovery Protocol (LLDP) interface manager operational model in tree format.
$ 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) ...........................

CDP YANG data model example

A CDP YANG data model example is a representation that

  • organizes CDP configuration settings and operational data using YANG’s hierarchical structure

  • supports both global and interface-level parameters through augmentation

  • enables automated discovery of Cisco devices and retrieval of neighbor details across the network.

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
In the CDP YANG model, the augmentation is expressed as:
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

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. The following example shows the CDP operational model in tree format. 

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

Unified data models

A unified data model is a configuration model that

  • provides full coverage of router functionality

  • offers a single abstraction for both YANG and CLI commands, and

  • replaces native schema-based models in supported Cisco IOS XR releases.

Unified models are available in the pkg/yang directory on Cisco IOS XR devices. The presence of um in the model name indicates the model is a unified model.

For example: Cisco-IOS-XR-um-<feature>-cfg.yang.

Accessing unified data models on the device

Use the mentioned shell command to access unified data models on the device

shell:Y
Router# run
[node]$ cd /pkg/yang
[node:pkg/yang]$ ls