YANG Data Models

YANG data modeling language, pyang validation tools, and model-driven telemetry on Cisco platforms.

YANG Fundamentals

YANG (Yet Another Next Generation) is a data modeling language for NETCONF and RESTCONF. It defines the structure of configuration and operational data — what you can read, write, and subscribe to on a network device.

Core YANG node types
Node Type     Description                              Example
─────────────────────────────────────────────────────────────────────
module        Top-level container for the model         ietf-interfaces
container     Grouping node (no data itself)            interface
leaf          Single value                              name, mtu, enabled
leaf-list     Ordered list of scalar values             dns-server addresses
list          Keyed collection of entries               interface entries keyed by name
choice        Mutually exclusive branches               address type (ipv4 or ipv6)
grouping      Reusable structure (like a template)      common-attributes
uses          Instantiates a grouping                   uses common-attributes
augment       Extends another model's structure         adds vendor-specific leafs
Minimal YANG module structure
module example-system {
  namespace "urn:example:system";
  prefix sys;

  import ietf-inet-types {
    prefix inet;
  }

  container system {
    leaf hostname {
      type string;
      description "The device hostname";
    }
    leaf-list dns-server {
      type inet:ipv4-address;
      ordered-by user;
      description "DNS server addresses";
    }
    list ntp-server {
      key "address";
      leaf address {
        type inet:ipv4-address;
      }
      leaf enabled {
        type boolean;
        default true;
      }
    }
  }
}

Three Model Families

Model Family      Namespace Prefix        Maintained By         Scope
──────────────────────────────────────────────────────────────────────────
IETF              ietf-*                  IETF (RFC standards)  Vendor-neutral
OpenConfig        openconfig-*            OpenConfig WG         Multi-vendor operational
Cisco Native      Cisco-IOS-XE-*          Cisco                 Platform-specific full coverage
                  Cisco-IOS-XR-*
                  cisco-nx-os-*
When to use which model
Use Case                              Recommended Model
───────────────────────────────────────────────────────────────
Multi-vendor interface config         openconfig-interfaces
Multi-vendor BGP config               openconfig-bgp
IOS-XE specific (EIGRP, DMVPN)       Cisco-IOS-XE-native
NX-OS specific (vPC, FEX)            cisco-nx-os-device
Standards-based ACLs                  ietf-access-control-list
Cisco native models cover everything the CLI can do. IETF and OpenConfig cover a subset but work across vendors. Start with OpenConfig for multi-vendor; fall back to native for platform-specific features.

pyang — Model Exploration Tool

Install pyang
pip install pyang
Clone Cisco YANG models from GitHub
git clone https://github.com/YangModels/yang.git ~/yang-models
ls ~/yang-models/vendor/cisco/xe/     # IOS-XE models by version
ls ~/yang-models/vendor/cisco/xr/     # IOS-XR models
ls ~/yang-models/vendor/cisco/nx/     # NX-OS models
ls ~/yang-models/standard/ietf/       # IETF standard models
ls ~/yang-models/experimental/openconfig/  # OpenConfig models
Generate tree view — the most useful pyang output format
pyang -f tree ietf-interfaces.yang
Output
module: ietf-interfaces
  +--rw interfaces
  |  +--rw interface* [name]
  |     +--rw name                        string
  |     +--rw description?                string
  |     +--rw type                        identityref
  |     +--rw enabled?                    boolean
  |     +--ro if-index                    int32
  |     +--ro admin-status                enumeration
  |     +--ro oper-status                 enumeration
  |     +--ro last-change?                yang:date-and-time
  |     +--rw statistics
  |        +--ro in-octets?               yang:counter64
  |        +--ro out-octets?              yang:counter64

Tree notation:

Symbol   Meaning
──────────────────────────
+--rw    Read-write (config data)
+--ro    Read-only (operational/state data)
+--x     RPC or action
+--n     Notification
*        List (multiple instances, keyed)
?        Optional leaf
Generate tree for a specific subtree — drill into one container
pyang -f tree --tree-path /native/interface ietf-interfaces.yang
Generate tree with depth limit — top-level overview only
pyang -f tree --tree-depth 3 Cisco-IOS-XE-native.yang
Validate a YANG model for errors
pyang --lint ietf-interfaces.yang
Convert YANG to other formats
# To UML diagram
pyang -f uml ietf-interfaces.yang -o interfaces.uml

# To DSDL (XML schema)
pyang -f dsdl ietf-interfaces.yang

# To JSON skeleton (sample instance data)
pyang -f sample-xml-skeleton ietf-interfaces.yang

Finding Models on a Device

List YANG models supported by a device via NETCONF capabilities
ssh admin@10.50.1.10 -p 830 -s netconf <<'EOF'
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities/>
</hello>
]]>]]>
EOF

The hello response lists every YANG module the device supports as capability URIs.

Extract model names from NETCONF hello — parse capabilities
ssh admin@10.50.1.10 -p 830 -s netconf <<'EOF' 2>/dev/null | grep -oP 'module=\K[^&]+' | sort -u
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities/>
</hello>
]]>]]>
EOF
Output (partial)
Cisco-IOS-XE-acl-oper
Cisco-IOS-XE-bgp-oper
Cisco-IOS-XE-interfaces-oper
Cisco-IOS-XE-native
ietf-interfaces
ietf-ip
openconfig-interfaces
openconfig-bgp

Deviations & Augmentations

Deviation — a vendor declares what parts of a standard model it does NOT support
module cisco-xe-ietf-interfaces-deviation {
  namespace "urn:cisco:params:xml:ns:yang:cisco-xe-ietf-interfaces-deviation";

  deviation "/if:interfaces/if:interface/if:type" {
    deviate replace {
      type string;  // Replace identityref with plain string
    }
  }

  deviation "/if:interfaces/if:interface/if:statistics/if:discontinuity-time" {
    deviate not-supported;  // This leaf is not implemented
  }
}
Augmentation — a vendor adds leaves to a standard model
module cisco-xe-ietf-interfaces-augment {
  namespace "urn:cisco:params:xml:ns:yang:cisco-xe-ietf-interfaces-augment";

  augment "/if:interfaces/if:interface" {
    leaf negotiation-auto {
      type boolean;
      description "Enable auto-negotiation on the interface";
    }
    leaf channel-group {
      type uint16;
      description "EtherChannel group number";
    }
  }
}
Find deviation models for a platform
find ~/yang-models/vendor/cisco/xe/17121/ -name "*deviation*" | head -10
Output
cisco-xe-ietf-interfaces-deviation.yang
cisco-xe-ietf-ip-deviation.yang
cisco-xe-openconfig-bgp-deviation.yang
cisco-xe-openconfig-interfaces-deviation.yang
Always check deviation models before using IETF or OpenConfig models against Cisco devices. The standard model may define features that the device explicitly does not implement. Deviations are per-platform and per-version.

Practical Workflow

End-to-end workflow: find a model, explore it, use it
# 1. Find what models the device supports
ssh admin@switch -p 830 -s netconf <<'EOF' 2>/dev/null | grep -oP 'module=\K[^&]+' | grep -i interface
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"><capabilities/></hello>
]]>]]>
EOF

# 2. Explore the model tree
pyang -f tree --tree-depth 4 ~/yang-models/vendor/cisco/xe/17121/Cisco-IOS-XE-native.yang \
  --path ~/yang-models/vendor/cisco/xe/17121/ \
  --tree-path /native/interface

# 3. Check for deviations
pyang -f tree ~/yang-models/vendor/cisco/xe/17121/cisco-xe-openconfig-interfaces-deviation.yang \
  --path ~/yang-models/vendor/cisco/xe/17121/

# 4. Use the model via RESTCONF (see restconf-quick-reference)
# or NETCONF (see netconf-quick-reference)