NHPREP — Hands-On CCNA, CCNP, CCIE Labs & Networking Courses

Objective

This lesson introduces the YANG data modeling language, compares Native vs OpenConfig models, and demonstrates how to explore YANG models on an IOS XE device using programmatic interfaces (NETCONF and RESTCONF). You will learn why YANG matters in production networks and how to discover the models and their data so you can automate configuration and telemetry reliably. In production, YANG models are used to build consistent, vendor-aware automation (for example, provisioning interfaces, ACLs, or retrieving structured telemetry across many routers).

Topology & Device Table

ASCII topology (management-plane only):

Device Table

Device	Interface	IP Address	Subnet Mask	Role
Admin-PC	eth0	192.0.2.2	255.255.255.0	Management workstation
IOSXE-RTR1	GigabitEthernet0/0	192.0.2.10	255.255.255.0	Target IOS XE device

Note: All example hostnames and domain names use lab.nhprep.com. Use the password Lab@123 if authentication is required for lab accounts.

Key Concepts (theory before hands-on)

YANG (Yet Another Next Generation) — a data modeling language (RFC 7950) used to express device configuration and state in a structured, machine-readable way. Think of YANG as the schema (like a JSON or XML schema) that defines what configuration nodes exist and how they are structured. In automation, these schemas translate vendor CLIs into model-driven APIs.
Native vs OpenConfig models — Native models are vendor-specific (for IOS XE these are Cisco-IOS-XE-* modules) and expose the full device feature set and behavior. OpenConfig are vendor-neutral community-driven models that provide consistent semantics across vendors but may not cover every proprietary feature. In production, use Native when you need vendor-specific features; use OpenConfig for multi-vendor consistency.
NETCONF / RESTCONF / gNMI — programmatic transports that carry YANG-modeled data. NETCONF operates over SSH (default port 830) and supports RPC operations such as , , . RESTCONF maps those operations to HTTP verbs (GET, POST, PUT, PATCH, DELETE) and commonly runs over HTTPS (default port 443). Choose based on tooling, security model, and data formats required.
Model discovery & capabilities — before you automate, discover which YANG modules the device exposes (their names, revisions, and features). NETCONF exposes a exchange of capabilities; RESTCONF can expose the YANG module or an ietf-yang-library endpoint returning available modules. Knowing the modules prevents schema mismatches and is crucial at scale.
Practical production note: When onboarding hundreds or thousands of devices, Day 0 automation (Secure ZTP) and Day 1 configuration use YANG-based interfaces to ensure device configuration is consistent and auditable. YANG models tie directly into intent-based workflows and telemetry.

Step-by-step configuration

We will not change device configuration in this lesson. Instead, we will discover YANG modules and read native configuration data using RESTCONF and observe NETCONF capabilities. Each step includes commands, why they matter, and verification.

Step 1: Validate connectivity and basic reachability

What we are doing: Ensure your Admin-PC can reach the IOS XE management IP. RESTCONF and NETCONF require IP connectivity; if the transport fails, you cannot retrieve YANG models.

# From Admin-PC (Linux shell)
ping -c 3 192.0.2.10

What just happened: The ping verifies IP-level connectivity to the device's management interface. If ICMP replies are returned, the network path is usable and higher-level protocols (SSH/HTTPS) can be attempted.

Real-world note: In production, management-plane reachability must be secured and segmented (out-of-band or management VRF). Automation tooling typically runs from a trusted management network.

Verify:

# Expected ping output
PING 192.0.2.10 (192.0.2.10) 56(84) bytes of data.
64 bytes from 192.0.2.10: icmp_seq=1 ttl=255 time=1.23 ms
64 bytes from 192.0.2.10: icmp_seq=2 ttl=255 time=0.97 ms
64 bytes from 192.0.2.10: icmp_seq=3 ttl=255 time=1.01 ms

--- 192.0.2.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 0.97/1.07/1.23/0.11 ms

Step 2: Retrieve NETCONF capabilities (SSH to port 830)

What we are doing: Use an SSH netconf session to view the device's NETCONF capabilities (the initial exchange). This shows supported YANG modules and NETCONF features. NETCONF runs over SSH (default port 830).

# From Admin-PC - open a NETCONF SSH session (interactive)
ssh -p 830 admin@192.0.2.10
# When connected, the NETCONF server sends a <hello> XML with capabilities and expects the client <hello>.

What just happened: Connecting to port 830 triggers the NETCONF server on the device to send a capabilities message. The message lists supported NETCONF capabilities and potentially some advertised YANG module capability URIs. This lets your client know what RPCs and models are supported before any RPCs are exchanged.

Real-world note: Some devices require key-based/PKI authentication for NETCONF in production. NETCONF's SSH transport provides confidentiality and integrity for model-driven management.

Verify:

# Expected NETCONF <hello> snippet (device-initiated)
<?xml version="1.0" encoding="UTF-8"?>
<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:base:1.1</capability>
    <capability>http://cisco.com/ns/yang/Cisco-IOS-XE-native?module=Cisco-IOS-XE-native&amp;revision=2023-01-01</capability>
    <capability>http://openconfig.net/yang/interfaces?module=openconfig-interfaces&amp;revision=2020-10-01</capability>
    <!-- additional capabilities -->
  </capabilities>
</hello>

Step 3: Read native configuration via RESTCONF (HTTPS GET)

What we are doing: Use RESTCONF to GET the top-level native configuration model. RESTCONF maps YANG data to HTTP semantics and is convenient for tools that prefer HTTP/JSON. We will request JSON format and authenticate with a lab account.

# From Admin-PC (use curl)
curl -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://192.0.2.10:443/restconf/data/Cisco-IOS-XE-native:native

What just happened: This HTTP GET requests the device's "native" container (the vendor-native schema) via RESTCONF. The device responds with JSON conforming to the Cisco-IOS-XE-native YANG module, exposing structured configuration (interfaces, routing, etc.). The Accept header indicates we want YANG-formatted JSON.

Real-world note: In production, RESTCONF should be used over HTTPS with strong certificates and role-based access controls. Accepting self-signed certs (-k) is for lab only.

Verify:

# Expected JSON response snippet (abridged for clarity)
HTTP/1.1 200 OK
Content-Type: application/yang-data+json

{
  "Cisco-IOS-XE-native:native": {
    "hostname": "IOSXE-RTR1",
    "interface": {
      "GigabitEthernet": [
        {
          "name": "0/0",
          "description": "Mgmt",
          "ip": {
            "address": {
              "primary": {
                "address": "192.0.2.10",
                "mask": "255.255.255.0"
              }
            }
          }
        }
      ]
    },
    "aaa": { /* AAA config if present */ }
    /* additional native configuration nodes */
  }
}

Step 4: Discover available YANG modules (ietf-yang-library via RESTCONF)

What we are doing: Query the device's YANG library to list available modules and revisions. Knowing exact module names and revisions avoids schema mismatch when building payloads or validation in automation tools.

# From Admin-PC
curl -k -u admin:Lab@123 -H "Accept: application/yang-data+json" \
  https://192.0.2.10:443/restconf/data/ietf-yang-library:modules-state

What just happened: The device responds with a modules-state container listing installed YANG modules, their name, revision, namespace, and features. Automation tooling uses this to validate payloads and to dynamically generate code or forms.

Real-world note: Some IOS XE versions provide a YANG repository on-device. At scale, tooling will cache these module lists to reduce repeated discovery queries.

Verify:

# Expected JSON response snippet (abridged)
HTTP/1.1 200 OK
Content-Type: application/yang-data+json

{
  "ietf-yang-library:modules-state": {
    "module": [
      {
        "name": "Cisco-IOS-XE-native",
        "revision": "2023-01-01",
        "namespace": "http://cisco.com/ns/yang/Cisco-IOS-XE-native",
        "schema": "/yang/Cisco-IOS-XE-native@2023-01-01.yang"
      },
      {
        "name": "openconfig-interfaces",
        "revision": "2020-10-01",
        "namespace": "http://openconfig.net/yang/interfaces",
        "schema": "/yang/openconfig-interfaces@2020-10-01.yang"
      }
      /* more modules */
    ]
  }
}

Step 5: Use YANG Suite (conceptual exploration)

What we are doing: YANG Suite (a graphical tooling example) loads device modules and allows interactive exploration, payload generation, and RPC testing. In a lab you would point YANG Suite at RESTCONF or NETCONF endpoints and import the device models.

# Conceptual actions (no device CLI)
# 1. In YANG Suite, create new Device with:
#    - Host: 192.0.2.10
#    - Protocol: RESTCONF (HTTPS) or NETCONF (SSH)
#    - Port: 443 for RESTCONF, 830 for NETCONF
#    - Username: admin
#    - Password: Lab@123
# 2. Connect and import modules; explore native and OpenConfig models visually.

What just happened: Tools like YANG Suite use the RESTCONF/NETCONF discovery endpoints to fetch modules and build a tree view of available nodes and RPCs. This speeds payload creation and helps you validate JSON/XML against the correct schema.

Real-world note: Use GUI/YANG tools for rapid development, then export validated payloads to your automation pipelines (Ansible, Python scripts, or CI/CD).

Verify (conceptual):

# In the YANG Suite UI you should see:
# - A list of imported modules including Cisco-IOS-XE-native and openconfig-interfaces
# - A module tree where you can expand 'native' -> 'interface' -> 'GigabitEthernet'
# - Generated example payloads for GET and edit-config/POST actions

Verification Checklist

Check 1: Ping 192.0.2.10 from Admin-PC — verifies management reachability (use ping -c 3 192.0.2.10).
Check 2: Retrieve NETCONF capabilities — connect SSH to port 830 and observe the capabilities XML (use ssh -p 830 admin@192.0.2.10).
Check 3: Use RESTCONF GET to fetch Cisco-IOS-XE-native top-level container — confirms RESTCONF and that the device exposes native YANG model (use curl -k -u admin:Lab@123 https://192.0.2.10:443/restconf/data/Cisco-IOS-XE-native:native).
Check 4: Query the ietf-yang-library via RESTCONF to list modules and revisions — validates module discovery (use curl -k -u admin:Lab@123 https://192.0.2.10:443/restconf/data/ietf-yang-library:modules-state).

Common Mistakes

Symptom	Cause	Fix
RESTCONF GET returns 401 Unauthorized	Incorrect username/password or account lacks RESTCONF privileges	Confirm credentials (admin / Lab@123 in lab). Ensure account has RESTCONF/HTTPS access and correct RBAC roles.
NETCONF SSH connection refused on port 830	NETCONF not enabled or firewall blocking port 830	Verify NETCONF service enabled on device and that management network permits TCP/830. Use SSH on port 22 for CLI as a fallback.
Received JSON but payload schema does not match automation expectations	Using wrong module or wrong revision (schema mismatch)	Query ietf-yang-library to find correct module names/revisions and update your payloads to match the module revision.
Tooling says module missing or invalid	Device does not expose OpenConfig module or module revision differs	Use native module or obtain the device's module revision and adapt tooling to that revision; consider mapping native->OpenConfig where required.

Key Takeaways

YANG is the schema that defines device configuration and state in a structured, machine-readable form; you must discover the exact modules and revisions on each device before automating.
Native models expose vendor features; OpenConfig provides vendor-neutral abstractions. Choose based on whether you need vendor-specific capabilities or multi-vendor consistency.
RESTCONF and NETCONF are complementary transports. NETCONF uses SSH (port 830) with XML RPCs; RESTCONF maps YANG to HTTP verbs (port 443 commonly) and JSON/XML payloads — pick the transport supported by your tooling and security model.
Always validate capabilities first. Use NETCONF or the ietf-yang-library via RESTCONF to discover available modules — this prevents schema mismatch errors in automation.

Tip: In production, secure all programmatic interfaces with proper certificates, least-privilege accounts, and management-plane segmentation. Use YANG discovery to build resilient automation that adapts to device model variations.

This completes Lesson 1 of 7 for Lab 49: NETCONF & RESTCONF — you now understand YANG models, how to discover native vs OpenConfig models, and the first practical steps to explore device models using NETCONF and RESTCONF.

YANG Data Models

Objective

Topology & Device Table

Key Concepts (theory before hands-on)

Step-by-step configuration

Step 1: Validate connectivity and basic reachability

Step 2: Retrieve NETCONF capabilities (SSH to port 830)

Step 3: Read native configuration via RESTCONF (HTTPS GET)

Step 4: Discover available YANG modules (ietf-yang-library via RESTCONF)

Step 5: Use YANG Suite (conceptual exploration)

Verification Checklist

Common Mistakes

Key Takeaways