Mental model
Cisco objective 5.1 says “Describe the value of model driven programmability for infrastructure automation”.
Model-driven programmability means every device exposes the same YANG-defined data. YANG is the schema language; NETCONF (XML/SSH), RESTCONF (JSON/HTTPS), and gNMI (Protobuf/gRPC) are three different transports that all carry YANG-shaped data.
Compared to the old “SSH + screen-scrape show interface” world, model-driven is:
- Structured — data has typed fields, not free text to parse with regex.
- Consistent — asking the same question of the same model gives the same shape every time.
- Bidirectional — same tree you read is the tree you write.
- Streamable — gNMI pushes updates on change instead of you polling.
The before-and-after
Before (screen-scraping)
output = ssh.send("show ip interface brief")
# Parse free text:
for line in output.splitlines():
if line.startswith("GigabitEthernet"):
parts = line.split()
# fragile: columns move when IOS version changes
name, ip, _, _, status, protocol = parts[:6]
If Cisco adds a column to show ip int brief next IOS release, your parser breaks.
After (model-driven)
r = requests.get(
"https://10.0.0.1/restconf/data/ietf-interfaces:interfaces-state",
auth=("admin", "cisco"),
headers={"Accept": "application/yang-data+json"},
)
for intf in r.json()["ietf-interfaces:interfaces-state"]["interface"]:
print(intf["name"], intf.get("oper-status"))
Structured JSON. Field names come from the published YANG model. If Cisco adds a field, the existing code keeps working.
The four benefits
1. Machine-readable, structured data
JSON or XML with named fields and types. No regex. No fragile string splitting.
2. Standard CRUD operations
Same four verbs across every YANG container: GET, POST, PUT/PATCH, DELETE. Learn once, use everywhere.
3. Push instead of poll (gNMI)
Subscribe to a telemetry stream: /interfaces/interface/state/counters. Device pushes updates on-change (or every N ms). Server-side cost drops from “ask 1000 switches every 30 sec” to zero when nothing changed.
4. Cross-vendor compatibility (partially)
IETF standard models (ietf-interfaces, ietf-routing) work the same on Cisco, Juniper, Arista. Vendor-specific features (Cisco-IOS-XE-native) still exist but the “common 80%” is shared.
Where it shows up in Cisco land
- IOS XE and NX-OS both expose NETCONF (port 830), RESTCONF (443), and gNMI (50051).
- Catalyst Center and NSO are controllers that themselves speak NETCONF/RESTCONF upstream.
- gNMI telemetry is how modern dashboards (Cisco Nexus Dashboard, Grafana + telegraf) get sub-second interface counters.
Comparison: SNMP vs model-driven
| SNMP | Model-driven (NETCONF/RESTCONF/gNMI) | |
|---|---|---|
| Age | 1988 | 2011+ |
| Model | MIBs (SMI schema) | YANG |
| Transport | UDP (SNMPv1/2c unencrypted) or SNMPv3 | SSH, HTTPS, gRPC |
| Payload | BER-encoded binary | XML / JSON / Protobuf |
| Write support | Yes but rare in practice | Yes, first-class |
| Streaming | No (traps are per-event, limited) | Yes (gNMI subscribe) |
| Scope | Mostly reads for monitoring | Full read + write + stream |
SNMP is not going away for legacy monitoring. Model-driven is where new tooling is being built.
FAQ
Do I need to learn YANG to use RESTCONF? Enough to read a small snippet and know what a leaf vs container vs list is. See the YANG + RESTCONF topic.
Can I replace SNMP with gNMI today? On modern Cisco gear, yes. gNMI telemetry is strictly better for high-rate counters. SNMP persists for legacy devices and third-party integrations.
Is OpenConfig competing with Cisco YANG? OpenConfig is an industry-group alternative YANG module set, broader scope. Cisco ships both: standard IETF models, OpenConfig models, and vendor-specific Cisco-* models. All coexist on the same device.
Is model-driven only for configuration, or also for state? Both. YANG models distinguish config true (writable) vs state (read-only operational data). Same tree.