6. Automation and Configuration — 10%¶
What: NVUE and Ansible methods for expressing, validating, and applying repeatable network configuration.
Why: Automation reduces manual drift but can also amplify an incorrect change across many devices.
How: Inspect desired and live state, validate changes on a canary, apply in controlled batches, verify outcomes, and keep a rollback path.
NVUE configuration workflow and templates¶
What: NVUE is a structured configuration and operational interface for supported Cumulus Linux systems; templates reuse configuration patterns.
Why: Declarative, repeatable configuration can reduce drift while making changes easier to review across devices.
How: Inspect current state, stage and validate intended changes, apply using the documented release workflow, then verify operational state and rollback readiness.
NVIDIA User Experience (NVUE) provides a structured way to configure and inspect supported Cumulus Linux systems. Learn the distinction between configuration intent, operational state, and the commands/API used to manipulate them. A common workflow is to inspect current state, stage a candidate change, review or validate it, apply/commit it, and verify resulting operational state. Exact syntax and transaction behavior vary by release; practice using the documentation for the target version.
Templates make a configuration pattern reusable across devices. Use variables for device-specific values and keep shared intent consistent. Before rollout, check interface names, platform support, dependencies, routing and QoS impact, and the available rollback method. A successful configuration command does not prove that links or protocols reached the intended state.
Ansible playbooks for network configuration¶
What: Playbooks automate tasks against inventory targets using variables, tasks, modules/APIs, conditions, and handlers.
Why: Automation improves repeatability and scale, but incorrect scope or non-idempotent tasks can multiply operational errors.
How: Trace target hosts and variable values, validate with supported check/diff modes, test on a canary, and inspect both task output and resulting network state.
Ansible automates repeatable tasks across an inventory. Understand the basic structure: inventory selects targets, variables supply values, tasks invoke modules or APIs, and handlers can respond to changes. A playbook expresses desired actions but may still be imperative depending on the module and task; idempotency means rerunning it should not create unintended repeated changes.
Read a playbook by tracing the target hosts, privilege/context, variables, conditions, module/API calls, and expected state. Review secrets handling, check mode/diff support, error behavior, and how partial failures are reported. Use a lab or staged rollout before applying network changes broadly.
Safe rollout and verification¶
What: A staged change process with explicit validation criteria and rollback conditions.
Why: Network changes can affect many hosts at once; a canary limits impact and reveals unexpected behavior before wider deployment.
How: Validate/render first, apply to a small batch, check control and data plane health against defined criteria, then expand or roll back.
Separate rendering/validation from applying changes. Apply to a small canary set, inspect command/API output and device state, then expand in controlled batches. Define success criteria and a rollback path in advance. After automation, verify both the saved configuration and live state: interface status, routing/neighbor sessions, QoS counters, and an appropriate end-to-end test.
Review questions: What does the play target? Which values vary per device? What makes a task safe to rerun? How do you detect a partial failure? What would you verify after changing an NVUE template?