4.3Controllers and programmable management (Catalyst Center, NETCONF, RESTCONF)

In a world of configuring devices one at a time from the CLI, configuration drift (identically-roled devices whose configs quietly diverge) and partial change failure (an error on device 17 of 40 leaving half the fleet applied) are chronic sources of incident. Programmable management attacks both structurally, and the keys are transactionality and declaring intent. NETCONF can stage edits in a candidate datastore and apply them all-or-nothing with commit, while RESTCONF lets an existing HTTP toolchain touch YANG data easily. Catalyst Center, in turn, takes "how you want things to be" rather than "how to do it," and looks after drift detection and assurance as well. Read this section with the view that the right mechanism for the same change shifts with scale and with the blast radius of failure.

4.3.1Cisco Catalyst Center (formerly DNA Center)

• Cisco Catalyst Center (formerly DNA Center) is the campus intent-based networking controller, driving operations through four workflows: Design (site hierarchy and common settings) -> Policy (group/SGT-based policy) -> Provision (deployment to devices and SD-Access fabric build) -> Assurance (monitoring and assurance). Its northbound Intent API (RESTful) lets external systems automate the same operations, while southbound it drives devices over NETCONF/RESTCONF/SNMP/CLI.
• Assurance continuously collects telemetry from devices, clients, and applications and quantifies health as a health score. Rather than simple threshold monitoring, it learns a baseline with machine learning, surfaces deviations as anomalies, and presents candidate root causes with recommended actions. Network Time Travel lets you replay what was happening to a given client at, say, 3 p.m. yesterday, which makes it strong for analyzing intermittent faults that are hard to reproduce.
• The AI-assisted workflow is not "the AI fixes things by itself": it is designed as baseline learning -> anomaly detection -> root-cause narrowing -> recommended action -> application upon operator approval, keeping the human in the decision. Its value during an incident is that it replaces manually running show across dozens of devices and correlating by hand with a pre-correlated set of candidates.

4.3.2NETCONF (XML, SSH 830, candidate and commit)

• NETCONF is a configuration management protocol exchanging XML-encoded RPCs over SSH on port 830; on IOS XE it is enabled with netconf-yang. The main RPCs are <get> (state plus config), <get-config> (config only), <edit-config> (changes), <lock>/<unlock>, and <commit>. The data structure is defined by YANG models.
• The datastores are running (the live configuration), candidate (an editing draft), and startup (boot configuration). Stacking multiple <edit-config> changes into candidate and finishing with <commit> guarantees that either all of it applies or none of it does (atomicity), which structurally prevents the "errored midway and half-applied" incident. <lock> excludes concurrent edits by another administrator, and confirmed-commit rolls back automatically unless a confirming operation arrives within a time window.
• Verify with show netconf-yang sessions and show netconf-yang statistics; errors come back as <rpc-error>. As a rule, choose NETCONF for automation that needs transactionality, locking, or subscriptions (telemetry).

4.3.3RESTCONF (HTTP plus JSON, CRUD to methods)

• RESTCONF exposes the same YANG data over HTTPS, with payloads in JSON or XML (Content-Type: application/yang-data+json); on IOS XE it is enabled with restconf plus ip http secure-server. URIs take the form /restconf/data/<YANG module>:<container>/<list>=<key>, for example /restconf/data/ietf-interfaces:interfaces/interface=GigabitEthernet1.
• You must know the CRUD-to-method mapping: create = POST, read = GET, replace (whole) = PUT, partial update = PATCH, delete = DELETE. PUT replaces the target resource wholesale, so elements you did not send disappear. Using PUT to change a single leaf loses the other settings--a classic incident in the field and a classic exam item; the correct choice is PATCH.
• Interpreting response codes is also common: 200 (successful read), 201 (created), 204 (success with no body, typical of update/delete), 400 (syntax or model mismatch), 401 (authentication failure), 403 (insufficient privilege), 404 (wrong URI path, module name, or key), 409 (conflict), and 5xx (server side). RESTCONF applies per request and has no transaction boundary like candidate/commit--the decisive difference from NETCONF.

You plan to push multiple interdependent lines of change--adding an ACL and modifying a route map--to 40 campus switches at once. The engineer, comfortable with RESTCONF, writes a Python script that issues a PATCH per change; on device 17 the route-map PATCH returns 400 Bad Request and the script halts, leaving that device in a half-state with the ACL applied but the route map not. The real problem here is not a script bug but the choice of mechanism. RESTCONF applies per request and has no transaction boundary like candidate/commit, so consistency spanning multiple requests cannot be guaranteed by design. Doing the same change over NETCONF lets you exclude other administrators with <lock>, stack both the ACL and the route map into candidate with <edit-config>, and finish with <commit> so that either all of it lands or none of it does. Adding confirmed-commit further means that if reachability is lost after the push and you cannot send the confirmation, the device rolls back automatically, avoiding the classic accident of locking yourself out of a remote box. Interpreting the 400 Bad Request matters too: it indicates a payload syntax problem or a mismatch with the YANG model, and should be distinguished from authentication (401), privilege (403), and a wrong URI (404). At a higher level, "consistent configuration across many devices" is not really a problem of hitting an API device by device: declaring it once as intent through Catalyst Center templates and the Intent API, then detecting and converging drifted devices, solves it structurally including the recurrence of drift. Conversely, the idea that "re-PUTting everything to all 40 devices will straighten it out" is the worst move, because PUT replaces the target resource wholesale and can wipe out existing settings you did not include.

4.3.4Section summary

• NETCONF uses XML over SSH 830, stacking edit-config into candidate and applying all-or-nothing with commit (lock for exclusion, confirmed-commit for automatic rollback)--the choice for consistent bulk change across many devices
• RESTCONF maps CRUD onto HTTPS methods with JSON (POST create, GET read, PUT replace, PATCH partial update, DELETE remove). With no transaction boundary, a failure partway leaves a half-applied state; use the response codes (400/401/403/404) to isolate the cause
• Catalyst Center (formerly DNA Center) provides intent-based operations across Design -> Policy -> Provision -> Assurance with an Intent API, while Assurance learns a baseline with ML to flag anomalies, candidate root causes, and recommended actions, and Network Time Travel replays past state