CloudVision Change Control for a Campus-Wide VLAN Push
An engineer uses CloudVision to push a new VLAN (VLAN 240, voice) and its associated SVI to 80 access switches across three buildings. The change is built as a single configlet applied to a container that includes all 80 switches. The container also includes 12 distribution switches that should not receive the SVI. The engineer schedules the change during business hours because "CloudVision has rollback." After the push, users in Building 2 report intermittent voice registration failures, and a distribution switch shows an unexpected SVI. The engineer wants to roll back immediately.
1. Identify the change-management failures in how this push was constructed and scheduled, and explain how the container scope caused the distribution SVI.
Read the worked answer
Failures:
- Scope error: the configlet was applied to a container that included 12 distribution switches that should not have received the SVI. Container membership defines blast radius; applying a configlet to a container applies it to every member. The distribution SVI is a direct consequence of over-broad container scope, not a CloudVision defect.
- No change control: a business-hours push of an 80-device change with no canary/pilot and no staged rollout violates change control. "CloudVision has rollback" is not a substitute for a controlled rollout - rollback restores prior state but does not prevent the outage window.
- Single configlet for 80 devices: no per-building staging, so a fault in one building's context propagates everywhere.
- Voice impact: pushing a voice VLAN/SVI during business hours risks registration failures if the SVI or VLAN is misconfigured on any device.
Judgement: the container, not the configlet, is the primary control point and must be verified before applying.
2. Describe the correct rollback procedure and the corrective change process for re-attempting the push.
Read the worked answer
Rollback: use CloudVision change control to revert the specific change (the configlet application) to the pre-change state, scoped to the affected devices. Verify on a sample of access switches and on the 12 distribution switches that the unexpected SVI is removed and voice VLAN state is restored. Confirm voice registration recovers in Building 2 before declaring rollback complete. Do not roll back unrelated changes; target the change ID.
Corrective process:
- Split the container: a voice-access container with only the 80 access switches; distribution excluded.
- Pilot: apply to one building (or a small canary set) first; verify SVI, VLAN, and voice registration.
- Stage by building with verification gates between stages.
- Schedule outside business hours or with an approved maintenance window; define success criteria and a rollback trigger.
- Use CloudVision change control with approval and a documented rollback plan referencing the change ID.