NETCONF, YANG, and Telemetry

NETCONF, YANG, and Telemetry

Quick Answer: NETCONF manages devices with structured XML RPCs, typically over SSH. YANG models define what configuration and state look like. Config is intended settings; operational state is live reality. Telemetry pushes streaming, model-driven metrics for real-time O&M, unlike classic SNMP polling that pulls on a schedule. NETCONF is not CLI; YANG is not a wire protocol by itself.

HCIA-Datacom V3.0 pairs SDN architecture and iMaster NCE with the protocols that make automation reliable. If you only know display and system-view, automation at scale stays brittle. Model-driven management gives machines a schema, transactions, and structured state—exactly what controllers and scripts need.

Why model-driven management exists

CLI is excellent for humans and emergency troubleshooting. It is poor as a large-scale API because:

• Output text formats change between versions
• Partial failures mid-script leave devices half-configured
• There is no strong machine-readable contract for every leaf

NETCONF + YANG address this with standardized operations and explicit data models. Controllers (including iMaster NCE) and tools (Python ncclient, Ansible modules) can get, edit, commit, and validate configuration against a known schema.

NETCONF fundamentals

NETCONF (Network Configuration Protocol) is an IETF protocol for installing, manipulating, and deleting device configuration and for retrieving state. Key properties at HCIA level:

NETCONF is not CLI

Critical exam trap: Sending NETCONF RPCs is not the same as pasting CLI commands into a channel. Even if a device also supports CLI, NETCONF operates on structured data trees defined by YANG. A controller does not “type” vlan 10 as free text inside NETCONF; it sets leaves in a model (conceptually).

Common NETCONF operations (conceptual)

• get-config — Retrieve configuration from a datastore
• edit-config — Merge/replace/delete configuration data
• get — Retrieve state (and sometimes config+state depending on usage)
• lock / unlock — Prevent conflicting writers
• commit — Activate candidate configuration when that capability exists

You do not need to memorize full XML samples for HCIA, but you should recognize that automation talks in RPCs + data trees, not free-form CLI banners.

YANG data models

YANG (Yet Another Next Generation) is a data modeling language. It describes:

• Hierarchies of containers, lists, and leafs
• Types and constraints (ranges, patterns, mandatory nodes)
• Distinctions between configuration and non-configuration (state) data
• RPCs and notifications in richer models

If NETCONF is the protocol (how you talk), YANG is the schema (what you are allowed to say). Devices publish YANG modules; controllers load those modules to understand the device API surface.

Exam trap: YANG is not “just JSON,” not “only SNMP MIB,” and not a replacement for SSH by itself. JSON may appear in RESTCONF or tooling, and SNMP uses SMIv2 MIBs—different modeling traditions. YANG is the standard partner for NETCONF (and is widely reused elsewhere).

Configuration versus operational state

A healthy automation loop writes config, then reads state to verify. Confusing the two causes classic failures: scripts that try to “configure” a counter, or operators who assume desired CLI intent matches live OSPF adjacency without checking state.

YANG modules mark nodes as config true (configuration) or config false (state) so clients know what edit-config may change.

Telemetry versus traditional SNMP polling

Operations teams need continuous visibility: CPU, interface errors, latency, table scales, wireless client counts, and more. Two philosophies:

SNMP pull (traditional)

• NMS polls devices on an interval (pull model)
• Data modeled in MIBs (SMIv2)
• Simple and ubiquitous, but high scale means many polls, coarser intervals, and more load
• Traps/informs can push asynchronous events, but bulk performance data is still often polled

Telemetry push (model-driven streaming)

• Device streams subscribed data to collectors (push model)
• Data is typically model-driven (YANG-related pipelines; product transports may include gRPC/gNMI-class mechanisms—know “streaming/push,” not every encoding)
• Suited to near real-time analytics, AIOps, and SDN assurance dashboards (including NCE-class analytics)
• Scales better for frequent fine-grained metrics than aggressive SNMP polling

Exam trap: Telemetry is not “just another name for SNMP traps.” Traps are event-ish notifications; telemetry emphasizes subscribed streams of performance and state for analytics. Also, telemetry does not replace configuration protocols—NETCONF still configures; telemetry observes.

How the pieces fit with SDN and NCE

  Intent / app  →  iMaster NCE  →  NETCONF (YANG config)
                         │
                         ├── reads operational state
                         └── consumes telemetry streams for assurance

1. Operator or northbound system expresses intent in NCE.
2. NCE renders device configuration and pushes via NETCONF (among other southbound methods).
3. Devices apply config and expose state.
4. Telemetry feeds analytics so NCE/O&M can detect drift or degradation.
5. Optional automation (Python/Ansible/OPS) may also speak NETCONF or complement the controller.

Python ncclient (awareness for automation questions)

HCIA automation topics often mention ncclient as a Python library for NETCONF over SSH: connect, send RPCs, edit configuration, close session. Remember the association Python + NETCONF → ncclient. Details of every API method are out of scope; the name and purpose are in scope alongside Ansible and OPS in the next chapter cluster.

NETCONF security notes

Because NETCONF commonly rides SSH:

• Use strong credentials or key-based authentication
• Restrict management-plane ACLs to NCE/automation source IPs
• Prefer dedicated management VRFs/VLANs where designed
• Treat NETCONF write access as highly privileged—equivalent to full config rights

These points connect to earlier AAA and remote-management lessons.

Quick comparison table for last-minute review

Exam traps checklist

• NETCONF ≠ CLI and ≠ a Huawei product name.
• YANG models structure; it does not forward packets.
• Config vs state must stay distinct in your mind.
• Telemetry = push/stream; SNMP polling = pull.
• SNMP traps ≠ full telemetry story.
• Controllers use these southbound tools; memorizing one XML sample is less valuable than knowing roles and relationships.

Study checklist

• Explain NETCONF over SSH with XML RPCs in one sentence.
• Define YANG as the modeling language for NETCONF data.
• Give one config example and one operational-state example.
• Contrast telemetry push with SNMP poll using a two-column mental table.
• Place NETCONF/YANG/telemetry under iMaster NCE in a southbound/assurance diagram.