Back
Lesson 2 of 6

Native vs OpenConfig Models

Objective

Compare Cisco-native YANG models with OpenConfig models using RESTCONF reads from an IOS XE device. Understand the differences in structure, vendor-specific extensions, and why multi-vendor standardization matters in production telemetry and automation.

Introduction

In this lesson we will retrieve YANG modules and modelled data from an IOS XE device using RESTCONF and compare a vendor-native model (Cisco-IOS-XE-native) with its equivalent in the OpenConfig model set (openconfig-interfaces). This matters because in production, automation and telemetry pipelines must either understand vendor-specific details or rely on a common schema (OpenConfig) to be portable across many vendors' devices. A real-world scenario: a multi-vendor campus where the NOC wants uniform interface counters and configuration fields in the monitoring platform — OpenConfig helps reduce parser and translation work.

Quick Recap

Refer to the topology used in Lesson 1. No new devices or IP addresses are added in this lesson. We will use the management host name lab.nhprep.com to access RESTCONF on the IOS XE device (per lab naming rules).

Key Concepts

  • YANG models: YANG defines the schema (structure, types, and semantics) for device configuration and operational data. Think of a YANG model as a contract describing "what data looks like" and how it can be changed.
  • Cisco-native models (Cisco-IOS-XE-native): Vendor-specific models that map directly to the device's CLI configuration and features. These include Cisco extensions and CLI-centric constructs (for example, many specific interface subcommands).
  • OpenConfig models: Vendor-neutral, community-defined schemas optimized for telemetry and consistent operational state across vendors. OpenConfig intentionally defines a smaller set of normalized fields (for example, standard interface identifiers and counters).
  • RESTCONF / NETCONF transport: RESTCONF (HTTP/HTTPS) is often used for programmatic reads and writes of YANG-modeled data; NETCONF (SSH) is used for RPCs and subscriptions. When you GET via RESTCONF, HTTPS GET requests return XML/JSON data that follows a YANG schema.
  • Why this matters: In production, telemetry collectors, SDN controllers, or automation pipelines either need per-vendor translators (to convert Cisco-native to an internal model) or rely on OpenConfig to reduce translation overhead. This impacts operational complexity and time-to-deploy for new hardware.

Tip: Think of Cisco-native models like a detailed blueprint drawn by the device vendor, and OpenConfig like an industry-standard form. The blueprint has more vendor-specific rooms; the form ensures every contractor (vendor) fills the same key fields.

Topology

Same topology as Lesson 1. No additional interfaces or IPs are introduced for this lesson. We will use the management host name lab.nhprep.com to reach the device RESTCONF endpoint.

Device Table

DeviceRoleManagement Hostname
Router1IOS XE device used for YANG/RESTCONF readslab.nhprep.com

Important: When following examples that use credentials, the lab username/password for RESTCONF in these exercises is admin / Lab@123 (do not use these credentials in production).

Steps

Step 1: Discover available YANG modules

What we are doing: Query the device's YANG module library so we can see which YANG modules are exposed by the device (both Cisco-native and OpenConfig). Knowing which modules are present is the first step before asking for configuration or operational data.

curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/ietf-yang-library:modules-state/module

What just happened: This HTTPS GET requests the YANG module list from the device's RESTCONF server. The device answers with a JSON array of modules and their revisions. RESTCONF returns data that conforms to the YANG model "ietf-yang-library" (the standardized repository of modules a device supports).

Real-world note: In production, collectors will first consult the YANG module list to decide which schemas to parse or which RPCs to call. Different IOS XE releases expose different module revisions; always record the module revision used by your automation.

Verify:

curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/ietf-yang-library:modules-state/module

Expected output (complete):

[
  {
    "name": "Cisco-IOS-XE-native",
    "revision": "2023-01-15",
    "namespace": "http://cisco.com/ns/yang/Cisco-IOS-XE-native",
    "conformance-type": "implement"
  },
  {
    "name": "openconfig-interfaces",
    "revision": "2022-09-01",
    "namespace": "http://openconfig.net/yang/interfaces",
    "conformance-type": "implement"
  },
  {
    "name": "ietf-interfaces",
    "revision": "2018-02-20",
    "namespace": "urn:ietf:params:xml:ns:yang:ietf-interfaces",
    "conformance-type": "implement"
  }
]

Step 2: Read Cisco-native interface configuration

What we are doing: Retrieve the vendor-native interface configuration tree. This demonstrates how Cisco maps CLI configuration into its YANG model (native). We look at the interface container and the schema the vendor uses.

curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/Cisco-IOS-XE-native:native/interface

What just happened: The device returned the "native/interface" subtree as defined by the Cisco-IOS-XE-native YANG model. Vendor-native models mirror CLI commands (for example, interface sub-commands, descriptions, IP addressing) and include Cisco-specific features and types.

Real-world note: The native model is the single source of truth for features that only the vendor supports — for example, special QoS maps or hardware-specific options. If your automation needs exact CLI parity (to push config identical to an engineer's CLI), the native model is required.

Verify:

curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/Cisco-IOS-XE-native:native/interface

Expected output (complete):

{
  "Cisco-IOS-XE-native:interface": {
    "GigabitEthernet": [
      {
        "name": "1",
        "description": "Uplink to Core",
        "shutdown": false,
        "ip": {
          "address": {
            "primary": {
              "address": "10.10.1.1",
              "mask": "255.255.255.0"
            }
          }
        }
      },
      {
        "name": "2",
        "description": "To Access Switch A",
        "shutdown": false
      }
    ],
    "Loopback": [
      {
        "name": "0",
        "description": "Router loopback",
        "ip": {
          "address": {
            "primary": {
              "address": "192.0.2.1",
              "mask": "255.255.255.255"
            }
          }
        }
      }
    ]
  }
}

Step 3: Read OpenConfig interface operational/state data

What we are doing: Query the OpenConfig interfaces operational state to see how the vendor maps operational data (for example, interface enabled flag and counters) into the vendor-neutral OpenConfig schema. This demonstrates the uniform fields OpenConfig provides.

curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/openconfig-interfaces:interfaces

What just happened: The device returned the OpenConfig "interfaces" container. OpenConfig focuses on operationally-relevant fields and normalizes names and types so a collector can treat different vendors uniformly. For example, OpenConfig uses a common "config" and "state" separation and standard counter names.

Real-world note: Use OpenConfig when you expect to collect the same operational metrics from devices of different vendors without writing per-vendor translators.

Verify:

curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/openconfig-interfaces:interfaces

Expected output (complete):

{
  "openconfig-interfaces:interfaces": {
    "interface": [
      {
        "name": "GigabitEthernet1",
        "config": {
          "name": "GigabitEthernet1",
          "description": "Uplink to Core",
          "type": "iana-if-type:ethernetCsmacd",
          "enabled": true
        },
        "state": {
          "name": "GigabitEthernet1",
          "admin-status": "UP",
          "oper-status": "UP",
          "counters": {
            "in-octets": 12345678,
            "out-octets": 23456789,
            "in-unicast-pkts": 123456,
            "out-unicast-pkts": 234567
          }
        }
      },
      {
        "name": "Loopback0",
        "config": {
          "name": "Loopback0",
          "description": "Router loopback",
          "type": "iana-if-type:softwareLoopback",
          "enabled": true
        },
        "state": {
          "name": "Loopback0",
          "admin-status": "UP",
          "oper-status": "UP",
          "counters": {
            "in-octets": 0,
            "out-octets": 0
          }
        }
      }
    ]
  }
}

Step 4: Compare fields and map differences (native -> OpenConfig)

What we are doing: Manually compare specific fields (for example, interface description, IP address, counters) between Cisco-native and OpenConfig outputs. The goal is to identify mapping choices and gaps so you can design a translator or choose which model to consume.

# Get Cisco native interface GigabitEthernet 1
curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=1

# Get OpenConfig state for GigabitEthernet1
curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/openconfig-interfaces:interfaces/interface=GigabitEthernet1/state

What just happened: The first request returns the native config for GigabitEthernet1 (CLI-like structure). The second returns the OpenConfig operational state for the same interface. By comparing both responses you can determine:

  • IP addressing: native model contains the exact CLI IP structure; OpenConfig often expects IP config in a separate openconfig-interfaces augment or the IETF interface models.
  • Counters: OpenConfig exposes counters with standard names (in-octets, out-octets), while native counters may use different names or be in a different subtree.
  • Enabled/admin flags: OpenConfig clearly separates config vs state which is helpful for automation (you can assert desired config and read state separately).

Real-world note: When building telemetry collectors, implement a mapping table that maps native fields to OpenConfig equivalents. Over time, prefer telemetry channels that natively expose OpenConfig if your network is multi-vendor.

Verify:

# Native config output
curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=1

Expected native output (complete):

{
  "Cisco-IOS-XE-native:GigabitEthernet": [
    {
      "name": "1",
      "description": "Uplink to Core",
      "ip": {
        "address": {
          "primary": {
            "address": "10.10.1.1",
            "mask": "255.255.255.0"
          }
        }
      },
      "shutdown": false
    }
  ]
}

# OpenConfig state output
curl -s -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://lab.nhprep.com/restconf/data/openconfig-interfaces:interfaces/interface=GigabitEthernet1/state

Expected OpenConfig output (complete):

{
  "openconfig-interfaces:state": {
    "name": "GigabitEthernet1",
    "admin-status": "UP",
    "oper-status": "UP",
    "counters": {
      "in-octets": 12345678,
      "out-octets": 23456789
    }
  }
}

Verification

Verification Checklist

  • Check 1: Confirm device lists both Cisco-IOS-XE-native and openconfig modules.
    • How to verify: Step 1 curl to /restconf/data/ietf-yang-library:modules-state/module and confirm both module names appear.
  • Check 2: Confirm native interface config is retrievable.
    • How to verify: Step 2 curl to Cisco-IOS-XE-native:native/interface returns interface entries (e.g., GigabitEthernet).
  • Check 3: Confirm OpenConfig interface state is retrievable and contains standardized counters.
    • How to verify: Step 3 curl to openconfig-interfaces:interfaces returns interface/state/counters.

Common Mistakes

SymptomCauseFix
RESTCONF requests return 401 UnauthorizedUsing wrong credentials or RESTCONF not allowed for the userUse correct credentials (admin / Lab@123 in lab) or ensure user has RESTCONF access. Check AAA and HTTP/HTTPS server settings.
No openconfig modules listedDevice does not include OpenConfig modules (platform/IOS XE build)Confirm software version supports OpenConfig or enable model provisioning. Consult YANG module list (ietf-yang-library).
Missing counters/fields in OpenConfig responseDevice may expose counters in a vendor augment or under different subtreeQuery both native and OpenConfig models and map fields; implement translator logic for vendor augments.
RESTCONF responses are XML when expecting JSONAccept header not set correctlySet Accept: application/yang-data+json header (or use application/yang-data+xml for XML).

Key Takeaways

  • Cisco-native YANG models are vendor-specific and expose CLI-parity configuration; they are necessary when you need exact feature configuration or CLI-like behavior in automation.
  • OpenConfig provides a vendor-neutral view optimized for telemetry and uniform operational state; use OpenConfig to simplify multi-vendor collectors and dashboards.
  • Always discover the YANG modules on a device (ietf-yang-library) before designing collectors — module names and revisions determine available fields.
  • In production, plan a mapping approach: either consume Cisco-native models directly (and accept vendor-specific parsing) or prefer OpenConfig-capable devices and telemetry pipelines for consistent multi-vendor operations.

Warning: Production collectors should validate YANG module revisions; differences in revisions can introduce incompatible structural changes. Always test automation against the exact software version in your production devices.

Practice with Hands-On Labs

30 step-by-step labs for CCNA, CCNP Enterprise & Security