The automation portion of the CCIE Enterprise Infrastructure lab is the part candidates prepare for least effectively, and the reason is a misdiagnosis of what it asks. It is treated as a programming requirement bolted onto a networking exam, so people learn a language, and then find themselves in front of a task that a language does not help with.
What it actually asks is narrower and more familiar. A device offers several interfaces besides the command line, each carrying the same configuration in a different shape, and the work is knowing which one answers which question, reading something somebody else wrote well enough to find what is wrong with it, and recognising that the failure in front of you is a network failure wearing a status code.
This article covers what is genuinely being examined, which interfaces a device offers and when each applies, what reading a script actually requires, the failures that look like code problems and are not, and how to prepare for this section in a way that matches what it asks. It is written for the lab rather than for the written exam, and sits alongside the rest of the CCIE Enterprise Infrastructure lab certification track.
Every interface reaches the same configuration in a different shape, so the skill being examined is choosing the right one for the question and recognising that most failures are network failures presented as protocol errors.What Is Actually Being Examined?
What does the section ask for?
Working with a device through interfaces other than the command line, and interpreting something already written rather than producing it from nothing. The tasks are recognisably networking tasks — read this state, apply this configuration, react to this condition — expressed through a protocol and a data format instead of through a terminal. The blueprint is the authority on the exact topic list and it is worth reading directly rather than through anyone's summary, including this one.
A Deeper Dive into the Requirement
Interpretation rather than authorship
The realistic form of these tasks is a piece of work that exists and does not do what it should. Something is wrong with it, or it needs an adjustment, and the requirement is to find and make that change. That is a reading skill and a debugging skill, not a writing skill.
It also matches what the job looks like. Almost nobody starts from an empty file; almost everybody inherits something and has to make it work in a network it was not written for.
Why learning a language is the wrong preparation
The code involved is short and uses a small number of constructs. What makes a task difficult is not the language — it is knowing that this device needs a particular configuration before its interface answers at all, or that the path being requested belongs to a model this software version does not implement.
Those are networking facts. Somebody fluent in the language and unfamiliar with them is stuck; somebody who knows them and can read a loop is not. Time spent on language fluency beyond the basics buys very little here.
What the small number of constructs actually is
Making a request and checking what came back. Walking a structure to find a value. Iterating over a list of devices or interfaces. Formatting a string from a template. Handling the case where something failed. That is most of it, and all of it is visible in any example worth studying.
Being able to read those five things confidently, in an unfamiliar script, is the practical bar. Being able to write them from memory is nice and is not what is being tested.
The breadth question
The blueprint names several interfaces and several formats, which looks like a lot of ground. It is less than it appears because they overlap heavily: two of the interfaces carry the same models in different encodings, and the formats are three ways of writing the same nested structure.
Understanding the underlying idea — a tree of named values, described by a model, moved over some transport — converts a list of technologies into one concept with several surface forms. That is the efficient way to cover it.
! The same question, three interfaces. Identical answer.
!
! Command line
R1# show interfaces GigabitEthernet0/1 | include line protocol
!
! RESTCONF, from a workstation
$ curl -sk -u admin:pass -H "Accept: application/yang-data+json" https://10.1.1.1/restconf/data/ietf-interfaces:interfaces-state/interface=GigabitEthernet0%2F1/oper-status
{"ietf-interfaces:oper-status": "up"}
!
! NETCONF, same model, XML instead
$ ssh -s admin@10.1.1.1 -p 830 netconf
What the section is really testing
Whether you can operate a network through a machine interface without losing the ability to reason about the network. The failure mode it is looking for is somebody who can call an interface and cannot tell whether the answer makes sense, or who gets a protocol error and concludes the script is wrong when the device is not configured to answer.
Framed that way, the preparation follows: use the interfaces on a real device until their failures are familiar, and the code takes care of itself.
| Assumed to be tested | Actually tested |
|---|---|
| Writing a program | Reading one and fixing it |
| Language fluency | Five constructs, recognised reliably |
| Memorised model paths | Finding the path on the device |
| Framework knowledge | Which interface answers which question |
| Debugging code | Recognising a network fault in a status code |
Which Interface, and When?
How do they divide?
By what you are trying to do. A single read of current state is fastest over the web-style interface. A configuration change that must be validated, applied atomically and rolled back if it fails belongs to the interface with datastores and locking. Continuous state without polling is a telemetry subscription. A reaction that must happen on the device with no external system involved is on-box scripting. And anything touching many devices at once belongs to a controller's interface rather than to the devices.
A Deeper Dive into the Interfaces
The web-style interface
Requests over the same transport a browser uses, with paths that name a place in the model and a body in a common data format. It is the easiest to experiment with because an ordinary command-line tool can exercise it, and that makes it the right place to start learning the model structure.
Its limitation is transactional. A change is one request against one place in the tree; several related changes are several requests, and nothing ties them together. Where that matters, the other interface exists.
! Enable it. Both lines, plus authorization - see the next section.
R1(config)# ip http secure-server
R1(config)# restconf
!
! Read one thing
$ curl -sk -u admin:pass -H "Accept: application/yang-data+json" https://10.1.1.1/restconf/data/ietf-interfaces:interfaces/interface=Loopback0
!
! Change one thing. PATCH merges; PUT replaces.
$ curl -sk -u admin:pass -X PATCH -H "Content-Type: application/yang-data+json" -d '{"ietf-interfaces:interface":{"name":"Loopback0","description":"set by API"}}' https://10.1.1.1/restconf/data/ietf-interfaces:interfaces/interface=Loopback0
The session-based interface
A persistent session carrying structured operations: read a datastore, edit it, validate, commit, unlock. The datastore concept is what it adds — a candidate configuration that can be built up and applied as one unit, or discarded, so that a half-applied change is not a possible outcome.
Locking matters on a device several systems might be configuring. Without it, two changes interleave and the result belongs to neither.
! Enable it, and confirm the session is possible
R1(config)# netconf-yang
!
R1# show netconf-yang sessions
R1# show netconf-yang statistics
!
! From a workstation: what does this device actually support?
$ ssh admin@10.1.1.1 -p 830 -s netconf
! The hello it returns lists every capability and model. Read it.
Telemetry
A subscription: the device is told which part of the model to report and how often, and it pushes updates without being asked. That removes the polling loop entirely, which is the whole point — a hundred devices polled every ten seconds is a hundred requests every ten seconds, and a hundred subscriptions is none.
The two arrangements are the device connecting outward to a collector, or a collector connecting inward to the device. Outward is usual, because it works where the collector cannot open connections to every device.
! The device pushes; nothing polls it
R1(config)# telemetry ietf subscription 101
R1(config-mdt-subs)# encoding encode-kvgpb
R1(config-mdt-subs)# filter xpath /interfaces-ios-xe-oper:interfaces/interface/statistics
R1(config-mdt-subs)# stream yang-push
R1(config-mdt-subs)# update-policy periodic 1000
R1(config-mdt-subs)# receiver ip address 10.200.0.80 57000 protocol grpc-tcp
!
R1# show telemetry ietf subscription 101 detail
R1# show telemetry ietf subscription all receiver
On-box scripting
Two forms: a small event-driven mechanism that runs commands in response to a condition, and a container running a full scripting environment on the device itself. Both remove the dependency on an external system, which matters when the condition being reacted to is the network being broken.
That is their genuine advantage and the reason to know them. An external system reacting to a link failure needs to reach the device, and the link failure may be why it cannot.
! Event-driven, on the device, no external system
R1(config)# event manager applet LINK-DOWN
R1(config-applet)# event syslog pattern "LINK-3-UPDOWN.*GigabitEthernet0/1.*down"
R1(config-applet)# action 1.0 cli command "enable"
R1(config-applet)# action 2.0 cli command "show interfaces GigabitEthernet0/1"
R1(config-applet)# action 3.0 syslog msg "Captured state at failure"
!
! Or a full environment, on the device
R1(config)# iox
R1# guestshell enable
R1# guestshell run python3 /bootflash/check.py
The controller's interface
Where a controller manages the devices, its interface is the right one for anything affecting more than one of them. It knows the inventory, it applies changes consistently and it reports what happened, none of which a per-device approach provides.
The trade is that the controller's model is its own rather than the devices', so the shape of the data is different and the relationship to the device configuration is indirect. That is a separate thing to learn and it is where a multi-device task belongs.
| Task | Interface | Why not the others |
|---|---|---|
| Read one value now | Web-style | Others are heavier for one read |
| Change several things atomically | Session-based | Only it has datastores and locking |
| Watch state continuously | Telemetry | Polling does not scale |
| React when the network is broken | On-box | External systems may be unreachable |
| Anything across many devices | Controller | Per-device loses consistency |
What Does Reading a Script Require?
What are you looking for?
Five things, in order. Where it connects and with what credentials. What it asks for, which is a path into a model. What it does with the answer, which is walking a structure to a value. What it changes, and with which verb, because the verb decides what happens when the same thing runs twice. And what it does when something fails, which in a badly written script is nothing at all. Finding the fault is usually finding which of those five is wrong.
A Deeper Dive into Reading
The connection
An address, credentials and often a decision about certificate verification. Faults here produce the clearest errors and the most misleading conclusions, because an authentication failure on these interfaces frequently means authorization rather than authentication — covered in the next section.
Reading this part first also tells you which interface the script uses, which frames everything after it.
The request path
A path names a module and a place within it. Two things go wrong: the module is not implemented by this software version, or the path is right for a different model of the same thing. Both produce a not-found response that reads like a mistake in the script and is a mismatch with the device.
The fix is to ask the device what it supports rather than to adjust the path by guesswork. Every device can list its models, and that list is the authority for that device on that version.
! Ask the device what it implements. Do not guess.
$ curl -sk -u admin:pass -H "Accept: application/yang-data+json" https://10.1.1.1/restconf/data/ietf-yang-library:modules-state | python3 -m json.tool | head -40
!
! Or from the device itself
R1# show install active
R1# show platform software yang-management process
Walking the answer
The response is a nested structure and the script reaches into it by name. A fault here is usually a level too few or too many — reaching for a value that is inside a list rather than beside it.
The reliable technique is to print the whole answer once, look at its actual shape, and then write the access. Guessing the shape from documentation is how a correct-looking access fails on real data.
The verb
This is the one worth dwelling on. A verb that replaces produces the same result however many times it runs. A verb that adds produces a duplicate the second time, or an error. A verb that merges leaves anything it did not mention untouched, which is usually what is wanted and occasionally hides that a removal never happened.
A script that works and then fails on the second run has almost always chosen the wrong one. That is the most common single fault in this material and it is visible from reading the verb alone.
What it does when something fails
A script that checks the response code and stops is safe. One that assumes success and proceeds will apply the second half of a change after the first half failed, which on a configuration task is worse than doing nothing.
When reading someone else's, the absence of that check is itself a finding. When the task is to fix something, adding it is frequently the correct fix rather than a refinement.
# The five things to read, in order, in any script
import requests
requests.packages.urllib3.disable_warnings()
URL = "https://10.1.1.1/restconf/data" # 1. where
AUTH = ("admin", "pass")
HDRS = {"Accept": "application/yang-data+json",
"Content-Type": "application/yang-data+json"}
r = requests.get(f"{URL}/ietf-interfaces:interfaces", # 2. what path
auth=AUTH, headers=HDRS, verify=False, timeout=10)
if r.status_code != 200: # 5. failure handling
raise SystemExit(f"read failed: {r.status_code} {r.text[:200]}")
for intf in r.json()["ietf-interfaces:interfaces"]["interface"]: # 3. walking
print(intf["name"], intf.get("description", ""))
Reading for the network, not the code
The most useful question while reading is not "is this correct code" but "what does this do to the device". A loop applying a change to every interface in a list does something specific and possibly alarming, and noticing that is a networking judgement.
That is the skill the section is looking for and it is also the one that matters on the job, where the script that runs against production was written by somebody who has left. Reading this once is not the same as being able to do it under time pressure, which is what repetition against realistic CCIE lab practice scenarios is for.
What Goes Wrong That Is Not the Code?
What are the usual causes?
Four. The interface is not enabled, which produces a refused connection. The device's authorization configuration is incomplete, which produces an authentication error that is not about the password. The certificate is self-signed and the client was told to verify it, which produces a failure that has nothing to do with the device. And the requested path belongs to a model the device does not implement, which produces a not-found that looks like a typing mistake. All four are device configuration, not code.
A Deeper Dive into the Real Causes
The service that was never enabled
Each interface needs to be switched on, and some need a second thing switched on underneath them. A refused connection means nothing is listening, which is the easiest of these to diagnose and the one most often diagnosed as a network path problem instead.
Checking from the device itself — that the process is running and the port is listening — separates this from a filtering problem in one command.
The authorization requirement
This is the one that costs people the most time. These interfaces authenticate a user and then require that user to be authorized for an execution session, and a device with authentication configured and authorization absent will reject a correct password with a message about authentication.
The message is misleading and the fix is in the device's access control configuration rather than anywhere in the client. Knowing this in advance converts a long investigation into one line.
! The requirement that produces "authentication failed" with a correct password
R1(config)# aaa new-model
R1(config)# aaa authentication login default local
R1(config)# aaa authorization exec default local
!
R1(config)# username admin privilege 15 algorithm-type scrypt secret <password>
!
! Then confirm the process is actually running
R1# show platform software yang-management process
confd : Running
nesd : Running
syncfd : Running
ncsshd : Running
The certificate
A device presents a certificate it signed itself, which a client configured to verify certificates properly will reject. That is the client behaving correctly, and it is not a device fault.
In a laboratory the answer is to disable verification deliberately and know that you have. In production the answer is a certificate the clients trust. Disabling verification in production because it made the error go away is how an interface that carries full configuration authority ends up unauthenticated in one direction.
The model mismatch
A path copied from documentation or an article may belong to a model this device does not implement, or to a different version of it. The response is a not-found, which is indistinguishable from a typing error by inspection.
Asking the device for its model list resolves it definitively. This is worth doing once per platform and version and keeping, because it is the authority and everything else is somebody's recollection.
Native models against open ones
Devices implement two kinds: a vendor-specific model covering everything the device can do, and standard models covering a common subset portably. The standard ones work across vendors and do not reach everything; the vendor ones reach everything and do not transfer.
Choosing between them is a design decision with the usual shape: portability against completeness. For a task that must work on one platform, the vendor model is simpler; for anything intended to outlive a hardware refresh, the standard one is worth the limitation.
! The same interface, two models. Different paths, same device.
!
! Standard model - portable, partial
GET /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet0%2F1
!
! Vendor model - complete, specific to this platform
GET /restconf/data/Cisco-IOS-XE-native:native/interface/GigabitEthernet=0%2F1
!
! Which does this device have?
$ curl -sk -u admin:pass https://10.1.1.1/restconf/data/ietf-yang-library:modules-state | python3 -c "import sys,json;[print(m['name']) for m in json.load(sys.stdin)['ietf-yang-library:modules-state']['module']]" | sort
A diagnostic order
Connection refused means the service is off. An authentication error with correct credentials means authorization. A certificate error means the client, deliberately. A not-found means the model. Anything else is worth reading the response body for, because these interfaces return a description of what went wrong and it is usually specific.
Reading the body is the step people skip. The error message is in there, in the same format as everything else, and it names the problem far more precisely than the status code.
| Symptom | Cause | One-line fix |
|---|---|---|
| Connection refused | Service not enabled | Enable it |
| Authentication error, right password | Authorization missing | Execution authorization |
| Certificate verification failed | Self-signed certificate | Client setting, knowingly |
| Not found on a valid-looking path | Model not implemented | Read the device's model list |
| Bad request | Body does not match the model | Read the response body |
How Should You Prepare?
What is worth the time?
Enabling each interface by hand on a real device, repeatedly, until the enabling commands and their failures are familiar. Asking a device for its own model list and navigating it. Taking a working piece of work, breaking it deliberately, and fixing it back. Learning what each failure actually means rather than what it says. And knowing the handful of verbs and what each does when run twice. None of that is programming study and all of it maps directly to the tasks.
A Deeper Dive into Preparation
Enable everything by hand, several times
The commands are few and the dependencies between them are the part that matters. Doing it from memory on a fresh device, hitting the authorization failure, and fixing it, is worth more than any amount of reading about it — because the failure is the thing you will meet.
Doing it on two different software versions is worth more still, because the differences between versions are exactly the kind of thing that turns a prepared task into an unprepared one.
Navigate a model rather than memorising paths
Paths are long and version-dependent and nobody remembers them. What is worth having is the ability to start at the top of a model on the device and work down to the thing you want, which is a few requests.
That skill transfers to every model on every platform. A memorised path transfers to one model on one version, and stops working after an upgrade.
# Navigate down, do not guess. Three requests, any model.
$ B=https://10.1.1.1/restconf/data
$ H='Accept: application/yang-data+json'
!
$ curl -sk -u admin:pass -H "$H" $B/ietf-interfaces:interfaces | head -20
$ curl -sk -u admin:pass -H "$H" $B/ietf-interfaces:interfaces/interface=Loopback0
$ curl -sk -u admin:pass -H "$H" $B/ietf-interfaces:interfaces/interface=Loopback0/description
Break something and fix it
Take a script that works, change one thing so it does not, and repair it. Wrong credentials. Wrong path. Wrong verb. Missing failure check. A structure walked one level too deep.
Each of those produces a distinct symptom, and having seen each one deliberately means recognising it immediately under time pressure. That is a couple of hours of preparation that maps one-to-one onto what the tasks look like.
Know the verbs cold
What each one does, and specifically what each does when run a second time against the same target. That single question separates them cleanly and it is the fault that appears most often.
Four verbs, one question each. It is ten minutes of study and it covers a disproportionate share of what goes wrong.
# The only verb question that matters: what happens twice?
# GET nothing changes - safe any number of times
# PUT replaces the target - same result every time
# PATCH merges into the target - same result, leaves the rest alone
# POST creates under the target - second run: already exists
# DELETE removes it - second run: not found
!
# A script that must be safe to re-run uses PUT or PATCH.
Use the device's own tools
A device can show its sessions, its subscription state, its model list and the processes behind each interface. Those outputs are the fastest way to establish whether the device side is working before touching the client side.
Knowing four or five of those commands means a failing task is localised in seconds rather than debugged from the client end for twenty minutes.
! The device-side checks worth knowing by heart
R1# show platform software yang-management process
R1# show netconf-yang sessions
R1# show netconf-yang statistics
R1# show telemetry ietf subscription all
R1# show running-config | include restconf|netconf-yang|^aaa
R1# show logging | include DMI|NETCONF|RESTCONF
What to skip
Language study beyond reading fluency. Frameworks not named in the blueprint. Anything that cannot be exercised on a device you have access to. And any preparation source you cannot verify — a path or a command from an article that does not work on your device is worth less than nothing, because it costs time twice.
The discipline that helps: everything you learn should be something you have made work on a real device. What survives that filter is what the section asks about.
Blueprint framing
The CCIE Enterprise Infrastructure v1.1 blueprint contains an automation domain listing the specific technologies examined, and it is the authority. This article is one reading of what those topics require in practice; the topic list itself is short, published, and should be read directly before any preparation is planned around it.
| Preparation | Maps to | Time |
|---|---|---|
| Enable each interface by hand, twice | Every task's first obstacle | An afternoon |
| Navigate a model from the top | Any path, any version | An hour |
| Break and fix a working script | The task format itself | Two hours |
| Verb behaviour when run twice | The most common fault | Ten minutes |
| Device-side check commands | Localising a failure fast | Half an hour |
| Learning a language properly | Very little here | Skip it |
Conclusion
The automation section asks for networking work conducted through unfamiliar interfaces, and the realistic task is repairing something that exists rather than writing something from nothing. That makes the required skill reading and debugging rather than authorship, and it makes language study largely beside the point — the code involved is five recognisable constructs and what stops people is a device that is not configured to answer.
Choosing the interface follows from the question. One value now is the web-style interface. Several changes that must succeed or fail together need datastores and locking, which only the session-based one has. Continuous state without polling is a subscription. A reaction that must work when the network is broken belongs on the device. And anything across many devices belongs to the controller, whose model is its own.
Most failures are not code failures. A refused connection means the service is off. An authentication error with a correct password means authorization is missing, which is one line on the device and the single biggest time sink in this material. A certificate error is the client behaving correctly. A not-found on a plausible path means the model is not implemented here, and the device's own model list settles it. Read the response body rather than reasoning from the status code, know what each verb does when it runs twice, and make sure everything you learned works on a device you can reach. More CCIE Enterprise Infrastructure material — labs, protocol breakdowns and study guides — is collected on the SPOTO CCIE site.
External Links
- RFC 6241 — Network Configuration Protocol (NETCONF)
- RFC 8040 — RESTCONF Protocol
- RFC 7950 — The YANG 1.1 Data Modeling Language
- RFC 8341 — NETCONF Access Control Model
- RFC 8641 — Subscription to YANG Notifications for Datastore Updates
- RFC 8525 — YANG Library
- Cisco Learning Network — CCIE Enterprise Infrastructure
Reference Notes
- RFC 6241 specifies NETCONF, including the running, candidate and startup datastores and the lock operation used to prevent concurrent modification.
- RFC 6241 specifies the edit-config, validate and commit operations that allow a set of changes to be applied as a single unit.
- RFC 8040 specifies RESTCONF, defining the mapping of datastore operations onto HTTP methods and the data path format used to address elements.
- RFC 8040 states that POST creates a resource, PUT replaces it and PATCH merges into it, which determines the behaviour of a repeated request.
- RFC 8040 defines the error response format, which carries a structured description of the failure alongside the HTTP status code.
- RFC 7950 specifies YANG, the modelling language in which the data hierarchies addressed by both protocols are defined.
- RFC 7950 distinguishes configuration data from state data within a model, which determines which parts of a tree may be written.
- RFC 8525 defines the YANG library, by which a device reports the modules it implements and their revisions.
- RFC 8341 defines the NETCONF access control model, governing which operations an authenticated user is permitted to perform.
- RFC 8641 specifies subscriptions to datastore updates, the basis of periodic and on-change telemetry streams.
- Cisco documentation states that the programmatic management interfaces require AAA authorization for EXEC access to be configured, in addition to authentication.
- The CCIE Enterprise Infrastructure v1.1 unified exam topics include an automation domain; the published topic list is the authoritative statement of what is examined.