YANG Suite for Model Exploration

Objective

In this lesson you will deploy and use YANG Suite to browse, validate, and test YANG models against live network devices. This matters in production because model-driven tooling speeds safe, repeatable configuration and telemetry workflows — for example, validating a vendor YANG model before using it in an automated change pipeline prevents wide-scale misconfiguration. Real-world scenario: you run a network automation platform that must validate vendor and IETF models and exercise NETCONF/gNMI connections before committing large-scale changes during a maintenance window.

Topology

Refer to the topology presented in Lesson 1 for the device interconnections and management-plane addressing. This lesson does not add new physical devices; it deploys a tool that connects to your existing management network. The YANG Suite instance will be installed on a management host reachable from the devices in the Lesson 1 topology.

Device Table

Device	Role	Management IP
YANG Suite Server	Model exploration, dataset manager, device manager (Docker)	See Lesson 1 management network host
IOS XE Device	Target device for NETCONF / telemetry testing	See Lesson 1 device management IP

Tip: Keep the management network isolated and reachable only from your automation host and jump hosts. In production, this reduces the blast radius if a management service is compromised.

Key Concepts

• YANG models define the schema (data tree, types, constraints) for configuration and state. Think of a YANG model like a contract: the client and server both agree on field names and types before exchanging data.
• NETCONF / RESTCONF / gNMI transport differences: NETCONF uses SSH (default port 830) and XML RPC operations (get, get-config, edit-config); RESTCONF uses HTTPS (default port 443) and REST verbs; gNMI uses HTTP/2 + proto/gnmi (default port 9339). In production choose the transport that matches device support and your security posture.
• Model validation vs. device validation: Validating a YANG module locally checks syntax and semantic constraints; validating against a live device ensures the device supports the schema nodes and operational behavior you expect.
• Dial-in vs. Dial-out telemetry directions: Devices can accept management connections (dial-in) or push telemetry to collectors (dial-out). For IOS XE, NETCONF and RESTCONF are typically dial-in (device acts as server), while gRPC/dial-out telemetry pushes data to collectors when configured.
• Model-driven telemetry benefits: Using on-change or periodic publishing reduces polling overhead. In production, model-driven telemetry scales from device-level health to thousands of interfaces by sending only relevant updates.

Step-by-step configuration

Step 1: Deploy the YANG Suite Docker container

What we are doing: Pull and run the YANG Suite container image that provides the Model Manager, Device Manager, dataset and diff capabilities. Running the container is the first practical step to explore and test YANG models locally before connecting to live devices.

docker pull jeremycohoe/tig_mdt
docker run -ti -p 3000:3000 -p 57500:57500 --name yangsuite jeremycohoe/tig_mdt

What just happened:

• docker pull downloads the container image to the host so it can be instantiated.
• docker run -ti -p 3000:3000 -p 57500:57500 --name yangsuite <image> starts the container interactively, maps the container ports 3000 and 57500 to the host (so you can reach the web UI and any auxiliary ports), and names the container yangsuite. Port 3000 typically hosts the YANG Suite web UI or data visualizer; other mapped ports expose additional tooling interfaces. Port mapping makes the container's services reachable via the management host IP.

Real-world note: In production you would run YANG Suite behind a reverse proxy or load balancer, enforce TLS, and bind only to a management interface to avoid exposing tooling to untrusted networks.

Verify:

docker ps --filter "name=yangsuite" --format "table {{.Names}}\t{{.Image}}\t{{.Ports}}\t{{.Status}}"
NAMES      IMAGE                  PORTS                                           STATUS
yangsuite  jeremycohoe/tig_mdt    0.0.0.0:3000->3000/tcp, 0.0.0.0:57500->57500/tcp   Up 2 minutes

Step 2: Confirm container listening ports and service readiness

What we are doing: Verify the service inside the container is listening on the ports we mapped and that the web UI is reachable from the management host. This matters so we know the tool is available before we try to import models or connect devices.

docker exec yangsuite ss -lnt
curl -s -I http://localhost:3000

What just happened:

• docker exec yangsuite ss -lnt runs the ss command inside the container to list listening TCP ports. You should see the mapped ports listening (for example, :3000, :57500). This confirms the application accepted the mapped ports.
• curl -s -I http://localhost:3000 performs a simple HTTP HEAD request to check the web UI responds; an HTTP 200 or a redirect indicates the server application started.

Verify:

# Output from `docker exec yangsuite ss -lnt`
State      Recv-Q     Send-Q         Local Address:Port          Peer Address:Port
LISTEN     0          128                0.0.0.0:3000                0.0.0.0:*
LISTEN     0          128                0.0.0.0:57500               0.0.0.0:*

# Output from `curl -s -I http://localhost:3000`
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Content-Length: 5120
Connection: keep-alive

Tip: If HTTP returns 503 or no response, consult docker logs yangsuite for startup errors and ensure the host firewall allows the mapped ports.

Step 3: Import YANG modules into the Model Manager

What we are doing: Place your vendor and IETF YANG files into the YANG Suite model directory so the tool can parse, display, and validate them. This matters because you will want to compare model schemas and run diffs/dataset operations before using models against devices.

docker exec -u 0 yangsuite mkdir -p /opt/yangsuite/models
docker cp ./yang-modules/ietf-interfaces.yang yangsuite:/opt/yangsuite/models/ietf-interfaces.yang
docker exec yangsuite ls -l /opt/yangsuite/models

What just happened:

• mkdir -p creates the models directory where YANG Suite expects YANG files.
• docker cp copies a local YANG file (example ietf-interfaces.yang) into the container models directory. In production you would gather vendor models and IETF models into a curated repository.
• ls -l confirms the files are present inside the container; the Model Manager reads this directory to populate available modules.

Verify:

# Output of `docker exec yangsuite ls -l /opt/yangsuite/models`
total 8
-rw-r--r-- 1 root root 18234 Apr  1 12:00 ietf-interfaces.yang

Real-world note: Maintain versioned YANG module repositories. A mismatch between module revisions on the device and your local store is a common source of validation errors.

Step 4: Use Device Manager (conceptual UI step) to add a NETCONF/gNMI target

What we are doing: Configure a managed device entry in YANG Suite to test NETCONF or gNMI connectivity. This lets you validate supported YANG modules and run live RPCs without making persistent changes to the device.

# This is a conceptual "command" placeholder: the Device Manager is typically a web UI action.
# Example of a verification step using a simulated device connection check:
docker exec yangsuite tail -n 100 /var/log/yangsuite/device_manager.log

What just happened:

• Adding a device in the Device Manager binds a hostname/IP, transport (NETCONF gNMI RESTCONF), port (NETCONF 830, RESTCONF 443, gNMI 9339), and credentials. The application then attempts a session: NETCONF uses SSH to establish an RPC session (server responses include with capability list); gNMI uses TLS/HTTP2 with protobufs.
• Viewing the device manager log shows connection attempts and capability exchange results, confirming whether the device supports the YANG modules you intend to use.

Real-world note: In production always test with a read-only credential first; capability exchange reveals supported models without changing device config.

Verify:

# Sample tail of device_manager.log after a successful NETCONF connection
2026-03-15 10:23:01 INFO  [device-manager] Attempting NETCONF connection to 10.0.0.10:830
2026-03-15 10:23:02 INFO  [netconf] Received <hello> from 10.0.0.10 with capabilities:
2026-03-15 10:23:02 INFO  [netconf] - urn:ietf:params:xml:ns:netconf:base:1.0
2026-03-15 10:23:02 INFO  [netconf] - urn:ietf:params:netconf:capability:writable-running:1.0
2026-03-15 10:23:02 INFO  [device-manager] NETCONF session established to 10.0.0.10

Step 5: Validate a model against the live device and run a simple read RPC

What we are doing: Use Model Manager + Device Manager to perform a live get/get-config of a subtree (for NETCONF) or subscribe/read (for gNMI). This verifies the device supports the model nodes and returns operational/state information.

# Conceptual: trigger a "get" for /interfaces/interface on the device via the web UI.
# Verification via service log of the RPC and returned payload:
docker exec yangsuite tail -n 100 /var/log/yangsuite/rpc_engine.log

What just happened:

• The tool sends an RPC (NETCONF <get> or <get-config>) to request the interface subtree. For NETCONF, the device will respond with an XML payload containing configuration and/or state. The RPC engine log records request and response details, including XML payloads and any validation errors.
• If the device omits nodes, the capability exchange or returned payload reveals which modules or revisions are unsupported.

Real-world note: Use these validation reads during maintenance windows if your actions trigger device commands, and record the returned model revision to match against automation templates.

Verify:

# Sample rpc_engine.log showing the get response
2026-03-15 10:24:10 INFO  [rpc-engine] Sending NETCONF <get> filter=/interfaces/interfaces
2026-03-15 10:24:10 INFO  [rpc-engine] Received RPC reply from 10.0.0.10:
<rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="101">
  <data>
    <interfaces xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
      <interface>
        <name>GigabitEthernet0/0</name>
        <type xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type">ianaift:ethernetCsmacd</type>
        <enabled>true</enabled>
        <oper-status>up</oper-status>
      </interface>
    </interfaces>
  </data>
</rpc-reply>

Step 6: Use the Dataset / Diff features to compare configs

What we are doing: Capture a dataset (a snapshot of device state/config) and run a diff between two datasets or between a dataset and a YANG-derived template. This is important to detect unintended differences and prepare safe edits.

# Conceptual action: create a dataset via the UI; verify dataset files on disk:
docker exec yangsuite ls -l /var/yangsuite/datasets
docker exec yangsuite cat /var/yangsuite/datasets/device-10.0.0.10-interfaces.json

What just happened:

• Dataset creation collects operational/state/config data into JSON or XML files mapped from active YANG models.
• Listing and cat'ing the dataset file shows the stored snapshot you can diff with another snapshot or a desired-state template to compute edit-config operations.

Real-world note: Use diffs to produce minimal edit-config changes. In many automation workflows you create an edit plan from a diff and present it for approval.

Verify:

# Output of `ls -l /var/yangsuite/datasets`
total 16
-rw-r--r-- 1 root root 4096 Mar 15 10:25 device-10.0.0.10-interfaces.json
-rw-r--r-- 1 root root 2048 Mar 15 10:26 desired-interfaces.json

# Output of `cat /var/yangsuite/datasets/device-10.0.0.10-interfaces.json`
{
  "interfaces": {
    "interface": [
      {
        "name": "GigabitEthernet0/0",
        "type": "ianaift:ethernetCsmacd",
        "enabled": true,
        "oper-status": "up"
      }
    ]
  }
}

Verification Checklist

• Check 1: YANG Suite container running — verify with docker ps showing container yangsuite and mapped ports 3000 and 57500.
• Check 2: Service responding on port 3000 — verify HTTP 200 from curl -I http://localhost:3000.
• Check 3: Device NETCONF connection successful — verify device manager logs show <hello> capability exchange and session established.
• Check 4: Dataset captured — verify dataset JSON exists under /var/yangsuite/datasets and contains expected interface entries.

Common Mistakes

Symptom	Cause	Fix
YANG Suite web UI not reachable	Host firewall or security group blocking mapped port 3000	Open port 3000 on the management host firewall or bind to the correct interface
Device shows <rpc-reply> but missing expected YANG nodes	Device does not support that module revision or model	Check device capability list in logs; import the matching YANG module revision into Model Manager
NETCONF connection fails with authentication error	Incorrect credentials or missing SSH key / incompatible auth method	Verify credentials; test SSH session manually to the device management IP; use read-only account for validation
Dataset file missing expected state fields	Filter used in get/get-config omitted subtrees, or device omits operational data	Rerun get with wider filter or verify device supports operational state nodes for that model

Key Takeaways

• YANG Suite lets you centrally manage YANG modules, validate models, and test live interactions with devices before automation runs — reducing risk in production.
• Understand the transport: NETCONF (SSH/port 830), RESTCONF (HTTPS/443), and gNMI (HTTP2/9339) differ in encoding and operations; pick the mechanism that aligns with device support and organizational security.
• Always validate model revisions and capabilities via the NETCONF <hello> exchange or capability list before attempting edit-config operations.
• Use datasets and diffs to create minimal, auditable edit actions — in production these form the basis of safe, reviewable automation changes.

Warning: Never perform bulk configuration changes without first validating against a test device or staging environment. Model mismatches or unsupported nodes can lead to partial or broken configurations across many devices.

---

This completes Lesson 3: "YANG Suite for Model Exploration." In the next lesson we will connect YANG Suite to a lab device to perform an edit-config change safely using a generated diff.