NETCONF, gNMI & YANG Lab: Programmable, Multi-Vendor, in Minutes

NETCONF, gNMI, and YANG are the foundation of modern network programmability — but most people learn them from RFCs and vendor PDFs without ever sending a single RPC. The reference material teaches the protocol; almost nobody lets you actually run it on real multi-vendor gear without days of local setup.

This tutorial closes that gap. We spin up a two-node multi-vendor lab — Nokia SR Linux (built-in) and Arista cEOS (BYOI) — both of which expose native NETCONF on port 830 and gNMI (SR Linux on 57400, cEOS on 6030) with no enable dance. Then we push a YANG-modeled config with OpenConfig, and subscribe to a gNMI streaming-telemetry feed. Every step leads with a plain-English prompt to the NetPilot agent, then shows the real ssh/gnmic commands so you can verify by hand.

NETCONF vs RESTCONF vs gNMI — the 30-second map

Before the lab, the one table everyone searches for. All three are management interfaces over a YANG data model; they differ in transport, encoding, and what they are good at.

Bottom line: NETCONF is the mature, transactional config protocol; gNMI is the high-rate streaming-telemetry and config protocol built for gRPC-era automation. They share YANG as the data model. With NetPilot you can run NETCONF and gNMI side by side on real SR Linux and Arista cEOS — and RESTCONF too on cEOS — in a ~2-minute cloud lab, all driven from one plain-English prompt.

What is NETCONF? A connection-oriented protocol (RFC 6241) that runs an XML RPC layer over SSH on port 830. It models configuration and state as YANG-defined data, and supports a candidate datastore with atomic commit and rollback — the reason it remains the workhorse for config changes.

What is gNMI? The gRPC Network Management Interface, an OpenConfig project. It runs over gRPC/HTTP2, encodes data as protobuf, and adds a Subscribe RPC with STREAM, POLL, and ONCE modes — making it the protocol of choice for high-frequency streaming telemetry in hyperscale and AI-cluster networks.

Where YANG fits: YANG is the modeling language (RFC 7950) that defines the schema both protocols speak. OpenConfig is a vendor-neutral set of YANG models so that the same config path — say /interfaces/interface[name=ethernet-1/1]/config — works across SR Linux, cEOS, and other vendors.

Step 1 — Spin up the multi-vendor lab

The whole point is to skip the local containerlab install. SR Linux auto-runs its NETCONF server on 830 and a gNMI server on 57400; Arista cEOS exposes NETCONF on 830 and gNMI on 6030 once management APIs are on. NetPilot wires both up.

"Build a 2-node lab: one Nokia SR Linux node (srl1) and one Arista cEOS node (ceos1), connected back-to-back on ethernet-1/1 ↔ Ethernet1. Enable NETCONF and gNMI management on both. Assign srl1 ethernet-1/1 to 10.0.0.1/30 and ceos1 Ethernet1 to 10.0.0.2/30. Verify the two can ping each other."

The agent picks the right NOS for each node, deploys the topology to cloud ContainerLab, and applies the management config in each vendor's own syntax — SR Linux's gNMI/NETCONF server config versus Arista's management api stanzas — in parallel. In ~2 minutes you have two live, programmable nodes.

Direct CLI is always available. SSH into either node to confirm the management servers are listening. On Arista cEOS the config the agent applied looks like this:

ceos1# configure
ceos1(config)# management api netconf
ceos1(config-mgmt-api-netconf)# transport ssh def
ceos1(config-mgmt-api-netconf)# no shutdown
ceos1(config)# management api gnmi
ceos1(config-mgmt-api-gnmi)# transport grpc def
ceos1(config-gnmi-transport-def)# port 6030
ceos1(config-gnmi-transport-def)# exit
ceos1(config-mgmt-api-gnmi)# no shutdown
ceos1(config)# interface Ethernet1
ceos1(config-if-Et1)# no switchport
ceos1(config-if-Et1)# ip address 10.0.0.2/30
ceos1(config)# end
ceos1# show management api gnmi

On SR Linux the NETCONF and gNMI servers ship enabled in the default config, but OpenConfig must be explicitly enabled before you can push OpenConfig paths — a candidate containing OpenConfig statements is rejected while it is disabled. The agent enables it, then confirms the servers and assigns the interface:

# SR Linux CLI
srl1# enter candidate
srl1# set / system management openconfig admin-state enable
srl1# set / interface ethernet-1/1 admin-state enable
srl1# set / interface ethernet-1/1 subinterface 0 admin-state enable
srl1# set / interface ethernet-1/1 subinterface 0 ipv4 address 10.0.0.1/30
srl1# set / network-instance default interface ethernet-1/1.0
srl1# commit now
srl1# info system gnmi-server
srl1# info system netconf-server

Step 2 — Pull the running config over NETCONF

With both nodes up, the first programmability move is to read state over NETCONF. This is the <get-config> RPC every "how to use NETCONF" tutorial demonstrates — but here against a real, live multi-vendor pair.

"Open a NETCONF session to srl1 and ceos1 and show me each device's running interface configuration. Then summarize both into one table so I can compare how SR Linux and Arista model the same interface."

The agent opens a NETCONF session per device, sends the <get-config> RPC, and translates each vendor's XML reply into a single normalized table — the multi-vendor translation that turns two different schemas into one readable diff.

Verify by hand. NETCONF over SSH is just an interactive SSH subsystem. You can drive it raw:

# Open a raw NETCONF session (port 830) to Arista cEOS
ssh admin@ceos1 -p 830 -s netconf

The server replies with its <hello> advertising capabilities; you answer with your own <hello>, then send a <get-config> RPC. Each message is terminated with the NETCONF 1.0 framing marker ]]>]]>:

<?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>
  </capabilities>
</hello>
]]>]]>
<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-config>
    <source><running/></source>
  </get-config>
</rpc>
]]>]]>

For day-to-day work nobody hand-frames XML — the agent does it, or you use a client like netconf-console2, ncclient (Python), or gnmic's sibling tools. The raw session above is just to show there is no magic underneath: NETCONF is XML RPCs over an SSH subsystem on port 830.

Step 3 — Push a YANG-modeled config with OpenConfig

This is the heart of the lab: change configuration through a YANG model rather than CLI lines. We use OpenConfig so the same model path works on both vendors. The goal: set a description on the back-to-back interface on each device using the OpenConfig interfaces model.

"Using OpenConfig YANG, set the interface description to 'netpilot-uplink' on srl1 ethernet-1/1 and ceos1 Ethernet1. Push it as a NETCONF edit-config to the candidate datastore and commit, then confirm the description is in the running config on both."

The agent maps your intent onto the OpenConfig path /interfaces/interface/config/description, generates the correct edit payload for each device, writes it to the candidate datastore, and issues an atomic commit — the transactional safety NETCONF is known for. Because OpenConfig is vendor-neutral, your intent is one sentence even though the two NOSes have different native models underneath.

Verify by hand. The OpenConfig-modeled NETCONF <edit-config> payload the agent sends looks like this (Arista cEOS accepts OpenConfig natively):

<rpc message-id="2" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <edit-config>
    <target><candidate/></target>
    <config>
      <interfaces xmlns="http://openconfig.net/yang/interfaces">
        <interface>
          <name>Ethernet1</name>
          <config>
            <name>Ethernet1</name>
            <description>netpilot-uplink</description>
          </config>
        </interface>
      </interfaces>
    </config>
  </edit-config>
</rpc>
]]>]]>
<rpc message-id="3" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <commit/>
</rpc>
]]>]]>

You can do the equivalent over gNMI in one line with gnmic — same OpenConfig path, protobuf on the wire instead of XML:

gnmic -a ceos1:6030 -u admin -p admin --insecure \
  set --update-path "/interfaces/interface[name=Ethernet1]/config/description" \
      --update-value "netpilot-uplink"

That single gnmic set and the multi-line NETCONF <edit-config> produce the same result through the same OpenConfig model — which is exactly why YANG-modeled automation scales across vendors where per-vendor CLI scripting does not.

Step 4 — Subscribe to gNMI streaming telemetry

Polling SNMP every 30 seconds is the old world. gNMI's Subscribe RPC in STREAM mode pushes counter updates as they change — the model that hyperscalers adopted for AI-cluster and high-density fabrics. Let's stream interface counters off both nodes.

"Subscribe to interface counters on srl1 and ceos1 over gNMI in stream mode, sampling every 5 seconds. Show me in/out octets and any error counters for the uplink interfaces, and flag any interface where error counters are climbing."

The agent opens a gNMI Subscribe stream to each device on the OpenConfig counters path, samples at your interval, and aggregates both feeds into one live view — flagging climbing error counters across vendors so you do not have to watch two raw streams.

Verify by hand with gnmic, the reference open-source gNMI client. A streaming subscription on the OpenConfig counters path:

gnmic -a srl1:57400 -u admin -p admin --insecure \
  subscribe \
  --path "/interfaces/interface[name=ethernet-1/1]/state/counters" \
  --mode stream \
  --stream-mode sample \
  --sample-interval 5s

For Arista cEOS, point at its gNMI port and use its interface name:

gnmic -a ceos1:6030 -u admin -p admin --insecure \
  subscribe \
  --path "/interfaces/interface[name=Ethernet1]/state/counters" \
  --mode stream \
  --stream-mode sample \
  --sample-interval 5s

Each update arrives as a protobuf Notification with the counter path and value, streamed the instant the sample window closes. A one-shot --mode once (gNMI's ONCE mode) gives you a single snapshot instead of a continuous feed — useful for ad-hoc checks. You get the same OpenConfig path on both vendors; only the port and interface name change.

Why a cloud agent beats local setup here

The GitHub repos that teach hands-on NETCONF/gNMI (networkop/yang, the gnmic SR Linux labs) are excellent — but they assume you have a Linux host, Docker, containerlab, and a sourced image, which is days of setup before your first RPC. The reference incumbents (Cisco docs, the YANG book, IETF RFCs) teach the protocol but never let you run it.

NetPilot sits in that gap:

• No enable dance — SR Linux ships NETCONF/gNMI on by default; the agent flips on Arista's management APIs for you.
• Multi-vendor in one lab — push the same OpenConfig path to SR Linux and cEOS and watch them respond identically, the whole point of YANG-modeled automation.
• Plain English in, RPCs out — the agent writes the <edit-config>, the gnmic subscribe, and the per-vendor translation; full CLI is always there when you want to drill in.

For the underlying lab mechanics — how the cloud ContainerLab deploy works and how multi-vendor topologies come together — see ContainerLab in the Cloud and Multi-Vendor Labs with AI. To go deeper on the open routing stack you can pair with these NOSes, see FRRouting in the Cloud.

FAQ

What is NETCONF used for?

NETCONF is used for transactional network configuration. It runs XML RPCs over SSH (port 830), models config and state in YANG, and supports a candidate datastore with atomic commit and rollback — so a config change either applies fully or not at all. It is the mature, config-focused half of modern network programmability.

What is gNMI and how is it different from NETCONF?

gNMI (gRPC Network Management Interface) is an OpenConfig protocol that runs over gRPC/HTTP2 with protobuf encoding. Versus NETCONF, gNMI is built for high-rate streaming telemetry via its Subscribe RPC (STREAM/POLL/ONCE modes) and uses a more compact, faster transport. NETCONF excels at transactional config; gNMI excels at push telemetry and config at scale. Both use YANG as the data model.

NETCONF vs RESTCONF — which should I use?

Use NETCONF when you need transactional config with candidate/commit/rollback and full datastore semantics. Use RESTCONF when you want lightweight, REST-style CRUD over HTTP/HTTPS with JSON or XML — easier to call from web tooling but without NETCONF's full transaction model. RESTCONF (RFC 8040) is essentially NETCONF's data model exposed as a REST API.

What is OpenConfig and why does it matter for multi-vendor labs?

OpenConfig is a set of vendor-neutral YANG models. Because SR Linux and Arista cEOS both support OpenConfig paths like /interfaces/interface/config/description, the same NETCONF <edit-config> or gnmic set works across both vendors unchanged. That vendor-neutrality is the entire reason YANG-modeled automation scales where per-vendor CLI scripting does not.

Do I need to enable NETCONF on SR Linux and Arista cEOS?

Nokia SR Linux ships its NETCONF server (port 830) and gNMI server (57400) enabled in the default config — no enable step. Arista cEOS needs management api netconf and management api gnmi turned on, which NetPilot's agent configures for you when you ask for a NETCONF/gNMI lab. Then you can drive both from the agent or by hand with ssh -s netconf and gnmic.

Can I run NETCONF, RESTCONF, and gNMI side by side in one lab?

Yes. Both nodes expose NETCONF and gNMI over the same YANG data models — and Arista cEOS adds RESTCONF on top (SR Linux's management surface is JSON-RPC, gNMI/gNOI, NETCONF, and SNMP, not RESTCONF). So a single NetPilot lab lets you send a NETCONF <edit-config>, a gnmic Subscribe, and a RESTCONF REST call against cEOS, and compare them directly — the fastest way to learn the differences hands-on.

Copy-paste ready: Grab the NETCONF, gNMI & OpenConfig prompt from our example library — the SR Linux + cEOS programmability lab from this post, ready to run.

Ready to send your first RPC? Spin up a multi-vendor NETCONF/gNMI lab on the online network lab — the AI-native network emulator — and start at app.netpilot.io.