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) ...........................

LLDP global and interface-level configuration enhancement

LLDP (Link Layer Discovery Protocol) global and interface-level configuration enhancement

  • prevents LLDP global parameters configuration from automatically enabling LLDP on all interfaces, and

  • ensures that LLDP enablement is controlled explicitly at the interface level, maintaining granular control over LLDP behavior.

Table 1. Feature History Table

Feature Name

Release Information

Feature Description

LLDP global and interface-level configuration enhancement

Release 25.4.1

Introduced in this release on: Centralized Systems (8400 [ASIC: K100])(select variants only*)

* This feature is now supported on Cisco 8404-SYS-D routers.

LLDP global and interface-level configuration enhancement

Release 25.1.1

Introduced in this release on: Fixed Systems (8200 [ASIC: Q200, P100], 8700 [ASIC: P100, K100]); Centralized Systems (8600 [ASIC:Q200]); Modular Systems (8800 [LC ASIC: Q100, Q200, P100])

You can now configure LLDP (Link Layer Discovery Protocol) global parameters without automatically enabling LLDP on all interfaces by default. This feature provides a granular operational control of the LLDP interface-level configurations.

By aligning with OpenConfig models, this feature introduces a more efficient operational control where LLDP is enabled on an interface only when both global and interface-level LLDP configurations are enabled.

Previously, LLDP was enabled if either configuration was present, potentially leading to inconsistent behavior.

The feature introduces these changes:

CLI:

YANG Data Model:

  • Cisco-IOS-XR-um-lldp-cfg

(see GitHub, YANG Data Models Navigator)

How does this feature affect the OpenConfig and native YANG model behavior?

When you configure OpenConfig global LLDP parameters, the lldp interface-only configuration is automatically added to the native Cisco-IOS-XR-um-lldp-cfg YANG model to retain consistent OpenConfig behavior. This ensures that modifying global LLDP parameters through OpenConfig does not unintentionally enable LLDP on all interfaces. This behavior provides seamless alignment between OpenConfig and the native YANG model, ensuring predictable and consistent LLDP behavior across interfaces.

What happens when LLDP is configured globally without using this feature?

Without the lldp interface-only option, enabling LLDP globally through OpenConfig adds the LLDP container with global parameters in the native Cisco-IOS-XR-um-lldp-cfg YANG model, which in turn activates LLDP on all interfaces. This can lead to inconsistent LLDP behavior, particularly when users expect interface-level configurations to remain in control.

How does the new behavior differ from the old behavior?

Use the table to understand the difference in LLDP operational states between the old and new behaviors.

Table 2. OpenConfig LLDP behavior changes

If OpenConfig global LLDP is...

And OpenConfig interface-level LLDP is...

Then the new LLDP interface state is...

And the old LLDP interface state was...

enabled (default)

container not added state

disabled

enabled.

enabled

enabled (default—after adding the interface container)

enabled

enabled.

enabled

disabled

disabled

enabled.

disabled

enabled

disabled

enabled.

disabled

disabled

disabled

disabled.

What is the effect of global and interface-level LLDP configurations on interface states?

The table provides an overview of how different configurations affect the operational state of the LLDP interfaces.

Table 3. LLDP state based on global and interface-level configuration

If global LLDP is...

And interface-level LLDP configuration is...

Then the interface LLDP state is...

lldp

not configured

enable.

lldp interface-only

not configured

disable.

lldp interface-only

lldp enable

enable.

lldp

lldp enable

enable.

Configure LLDP global and interface-level configuration enhancement

Use this procedure to configure the LLDP interface-only feature on your router, allowing global LLDP parameters to be modified without automatically enabling LLDP on all interfaces.

Procedure

Step 1

Configure the LLDP interface-only parameter.

Example:
Router(config)# lldp
 Router(config-lldp)# timer 60
 Router(config-lldp)# interface-only
Router(config-lldp)# exit

Step 2

Verify the LLDP interface-only parameter and global parameters are correctly applied.

Example:
Router# show run lldp
Tue Jan 28 05:43:11.868 UTC
lldp
 timer 60
 interface-only
!

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