RESTCONF Script Breaks After an IOS-XE Upgrade

Each code points at a different layer, which is why they appeared in sequence.

401 Unauthorized: authentication, not authorisation. Either the script sent no credentials, or the service account was locked or rejected by TACACS+. A common trap is testing with a personal account that has an interactive login and then switching to an API service account whose password policy or TACACS+ shell profile differs. Verify with curl -k -u user:pass https://<device>/restconf/data/ietf-yang-library:modules-state and confirm RESTCONF itself is enabled (ip http secure-server, restconf).

406 Not Acceptable: authentication now works and the server is refusing the response format. The client asked for a representation it does not produce. Set the Accept header explicitly.

415 Unsupported Media Type: the server is refusing the request body format. A PATCH with a JSON body but no Content-Type, or a Content-Type of text/plain, is rejected before the YANG model is even considered.

Correct headers:

• GET: Accept: application/yang-data+json
• PATCH: Accept: application/yang-data+json and Content-Type: application/yang-data+json

If the script uses Python requests, set them per call rather than relying on a session default. Also send Accept: application/yang-data+json on the capability discovery call, since a 406 there usually looks like an authorisation failure in the logs and sends people down the wrong path.

The script hard-codes a path into a native YANG model, for example /restconf/data/Cisco-IOS-XE-native:native/interface. Native models are revised with every IOS-XE release, and a revision can rename a node, move a container or change a key. A path that resolves on one revision returns a 404 or an empty result on another even though the device is healthy. The 401 and 406 were incidental; the deeper problem is that the script assumes a fixed model surface across a fleet that is not on one release.

Resilient approach:

1. Discover capabilities before building requests. GET /restconf/data/ietf-yang-library:modules-state (or /restconf/data/netconf-state/capabilities) returns the exact module names, revisions and feature sets on that device. Cache the result per software version.
2. Validate against the model with pyang or yangsuite in CI, using the YANG files from the target release, so a model change is caught before deployment rather than in production.
3. Prefer standard models such as ietf-interfaces for read-only telemetry and use the native model only where the standard model lacks coverage. Standard models change far less often.
4. Version-pin the fleet where possible. A 220-switch estate split across two or three releases should be a deliberate decision, not drift.
5. Treat a model change as an API contract change: fail loudly with the discovered revision in the error message so the next engineer does not spend a day on a 404.

For pure counters, model-driven telemetry or SNMP polling may be a better fit than RESTCONF per device, because the polling cost scales with the fleet.

Use each tool for what it is good at, and be explicit about which system owns which configuration.

Catalyst Center templates for day-1 onboarding and compliance. They are designed for a large, mostly uniform Catalyst estate, they keep a running compliance view per device, and the template variables handle per-site differences such as management subnet, NTP servers and syslog targets. For 220 switches this replaces most of the bespoke scripting and gives a defensible audit trail of what changed and when.

Ansible for cross-platform, idempotent day-2 operations, particularly where NETCONF or RESTCONF modules are used. The 12-minute NETCONF runtime for 220 devices is a serialisation problem: raise the fork count, batch the inventory, and use serial with a failure threshold so one bad switch does not stall the run. Ansible is also where you enforce idempotency and a source of truth, which raw curl calls do not give you.

Raw RESTCONF for read-only checks and small, targeted operations: verifying a counter, checking a single interface state, or a quick remediation on one device. It is the wrong layer for fleet-wide configuration because it has no built-in state comparison, no drift detection and no rollback.

Against the audit requirement: Catalyst Center and Ansible both produce change records, and TACACS+ command accounting covers what reached the CLI. The gap to close is the privilege-15 service account: scope it to the API paths or roles it actually needs, rotate its credentials, and log every call, otherwise the audit trail shows 'the automation account did something' and nothing more.