Choosing a Configuration Transport for a Mixed-Fleet Refresh
Your team owns 420 network devices: 250 Catalyst switches running IOS-XE 17.9, 120 Nexus switches on NX-OS 9.3, and 50 legacy ISR routers stuck on IOS 15.2 because of an application certification. Six network engineers and two Python developers currently push changes with a mix of SSH scripts and copy-pasted CLI. Roughly 30% of changes require a follow-up fix, and an audit found two incidents where an ACL was applied but the matching route-map was not. The change window is 02:00-04:00. Leadership wants one automation stack and has two proposals: standardize on RESTCONF for every device that answers on port 443, or keep SSH+CLI and add TextFSM parsing. Neither proposal accounts for devices that expose only part of the required capabilities. You must recommend a transport strategy and define how the tooling should behave when a device advertises only part of the required feature set.
1. Recommend a per-device-class transport strategy. Justify each choice with the capability that makes it safe, and explain what the tool must verify before writing.
Read the worked answer
Start from capabilities, not from a vendor slogan. A device answering on port 443 does not mean RESTCONF is usable for transactional change.
- IOS-XE 17.9: advertise NETCONF 1.1 with candidate datastore and confirmed-commit. Use NETCONF for multi-element changes; RESTCONF is acceptable for single-resource CRUD where the YANG model is covered, but should not be the only path.
- NX-OS 9.3: NETCONF is present, but candidate datastore and confirmed-commit support are platform and release dependent. Query
:capabilitiesand the YANG library at session start; if candidate is not advertised, use checkpoint/rollback plus a diff plan. - IOS 15.2: no model-driven interface; SSH with structured parsing is the only option, so treat it as a compensating-rollback class, not an atomic class.
The tool must fail closed. If a device advertises only part of the required capability set, the job should refuse to write and raise a ticket rather than silently falling back to CLI. Silent fallback is how the ACL/route-map split happened. Encode the policy as a device-class matrix with tests, and record the negotiated capability set in the change record so audits can prove which semantics actually applied.
2. The ACL was applied but the route-map was not. Describe how you would make a multi-element change atomic or recoverable on each device class.
Read the worked answer
The incident happened because two config elements were treated as two independent tasks. Fix the abstraction, not just the playbook.
- Candidate plus confirmed-commit class: build one candidate edit containing both the ACL and the route-map, validate, commit confirmed with a 5-minute timeout, run parsed post-checks, then confirm. If the post-check fails or the session dies, the device rolls back automatically.
- Checkpoint class: create a checkpoint, apply both elements in one edit-config, verify, and roll back to the checkpoint on any failure. Hold a per-device lock for the duration.
- CLI class: capture pre-change running-config, apply the full command set in one SSH session, parse expected outputs, and keep explicit rollback commands ready. This is compensating rollback, not atomicity, so require a second approver and a shorter change window.
Expose transaction semantics in the inventory: atomic, compensating, or unsupported. The pipeline should select the strategy from that field and refuse to run a multi-element change against a device marked unsupported. Add a post-condition check that asserts the route-map references the ACL, which directly tests the relationship that broke.
3. What evidence would cause you to revise this transport recommendation?
Read the worked answer
Look for three kinds of evidence: coverage, failure behavior, and scale.
- Coverage: run a YANG coverage test that lists every model the workflow needs and compares it to each device's YANG library. If NX-OS candidate support is missing on a meaningful fraction of the fleet, the checkpoint path becomes the norm and the risk profile changes.
- Failure behavior: inject a mid-transaction disconnect and a failed post-check on each class. If confirmed-commit does not behave reliably, you cannot claim atomicity regardless of what the datasheet says.
- Scale: 420 devices with two developers means session setup and lock contention matter. If NETCONF session limits or CPU on the legacy ISRs cause timeouts, the CLI class may need a bastion or proxy rather than direct sessions.
Also watch for model gaps. If a required feature has no YANG model on IOS-XE 17.9, NETCONF and RESTCONF cannot cover it, so you need a documented CLI exception with the same guardrails rather than a quiet fallback.