Model-driven automation across mixed SR OS releases
A network team manages 200 Nokia 7750 SR routers. 140 run SR OS 22.10 with MD-CLI enabled; 60 run 19.10 and use classic CLI. The team's Python scripts use SSH and screen scraping to back up configurations and push ACLs. About 12% of runs fail because the pager prompt changes, a config contains 'exit all', or a device returns an ambiguous command. Failed pushes leave partial ACLs, and there is no rollback. The team wants to move to model-driven automation, keep the 19.10 devices in scope, and produce an audit trail for every change. A pilot showed that NETCONF over SSH works on the 22.10 devices with candidate datastore and confirmed commit; the 19.10 devices support NETCONF but only with running datastore and a limited set of YANG models. The ACL YANG model exists only on 22.10. The team has 6 months and two engineers.
1. Choose the automation protocol and datastore strategy for the 22.10 and 19.10 devices. Justify the choice.
Read the worked answer
Use NETCONF over SSH as the configuration protocol for both groups. On 22.10, use the candidate datastore with confirmed commit so a bad ACL can be rolled back automatically. On 19.10, use NETCONF with the running datastore, a scoped edit-config, and a pre-change backup; do not use screen scraping. Use YANG models where supported; because the ACL model exists only on 22.10, either upgrade the 19.10 devices or use validated CLI templates for ACLs on those devices. Use gNMI for streaming telemetry, not for configuration. This gives one audit trail and removes pager and prompt failures.
2. Design a change workflow that provides rollback and an audit trail for every ACL push.
Read the worked answer
Store intended configuration in Git. Validate YANG before connecting. For 22.10: lock, edit candidate, validate, confirmed commit with a 5-minute timeout, verify operational state, then confirm. For 19.10: back up running config, apply a scoped replace, verify, and roll back from backup on failure. Record job ID, device, before and after diff, user, and result in a central log or SIEM. Subscribe to NETCONF notifications for config changes. The audit trail should show both the intended change and the confirmed state.
3. What would you do about the 12% failure rate during the transition?
Read the worked answer
Classify the 12% failures: pager and prompt issues disappear with NETCONF; 'exit all' is a CLI artifact and is not valid in model-driven edits; ambiguous commands are eliminated by YANG validation. For the 19.10 CLI fallback, disable paging, use batch mode, parse with structured templates, and retry idempotently. Add pre-checks for model availability and a dry-run mode. Track failure reasons weekly and retire CLI paths as devices upgrade.