Data models and device APIs: YANG, NETCONF, RESTCONF and XML
Scripts that scrape CLI text break whenever the text changes. This chapter shows what replaces it: YANG data models, NETCONF and its candidate datastore, RESTCONF URLs and media types, the same interface written in XML and in JSON, streaming telemetry, and how the CLI, SNMP, NETCONF and RESTCONF compare.
What you'll learn
- Explain why scripts that screen-scrape CLI output break, and what a data model fixes.
- Read a small YANG model: module, container, list, key and leaf, and tell configuration data from state data.
- Describe a NETCONF change: SSH on port 830, get, get-config and edit-config, and the candidate and running datastores with lock and commit.
- Build and read a RESTCONF request: the URL that mirrors the YANG path, the HTTP method, and the JSON or XML media types.
- Compare the CLI, SNMP, NETCONF, RESTCONF and streaming telemetry, and choose one for a given job.
Why screen-scraping CLI output breaks
Before device APIs, automation meant screen-scraping: a script logs in over SSH, types a show command and pulls values out of the text by pattern or by column. That text was designed for a person reading a terminal, not for a program, so the script breaks whenever the text changes shape.
The exhibit shows how. A script that splits each line on spaces and reads the fifth field as the status gets up for Gi0/1, but administratively for Gi0/0, because that status is two words long. Nothing in the output warned it.
Scraping fails in other ways too. Names are shortened in one command and spelled out in another, columns move between software releases, long values are cut off, and errors come back as free text. Nothing marks which value is configuration and which is live state, and nothing can apply ten settings as one change.
R1#show ip interface brief Interface IP-Address OK? Method Status Protocol Gi0/0 10.1.0.1 YES manual administratively down down Gi0/1 10.1.20.1 YES manual up up Se0/0/0 unassigned YES manual administratively down down Se0/0/1 unassigned YES manual administratively down down
What a data model gives you
A data model is a published schema for a device's configuration and state. It names every value, gives it a type (a string, a whole number in a range, true or false), places it in a tree, and says whether it is configuration you can write or state you can only read. A program that knows the model never has to guess where a value is.
Three pieces work together. YANG is the language the models are written in. NETCONF and RESTCONF are protocols that carry data shaped by those models: NETCONF as XML over SSH, RESTCONF as JSON or XML over HTTPS. One model, such as the standard ietf-interfaces, can be read with either protocol and gives the same values.
- Standard models, from the IETF and from operator groups such as OpenConfig, describe common features the same way on every device that implements them.
- Native models describe one platform's own features in full: complete, but not portable to other devices.
8 more sections in this chapter, plus a 4-question quiz.
Modules 2–8 are part of the Course & Lab Pass and All-Access Max — start with a free account
You can see the title, summary, learning objectives and the opening sections. The rest of this chapter, like all of modules 2–8, comes with the Course & Lab Pass and All-Access Max. A free account opens Module 1: How Networks Work end-to-end and saves your labs — start there, no card required.
- Read every chapter in Module 1 — How Networks Work
- Save labs of up to 5 devices
- Save up to 3 topologies
- See the full course syllabus + chapter titles
Free account · no card required · compare plans any time