Change windows routinely edit underlay BGP and overlay EVPN together across the whole civic fabric with no canary leaves. What best practice should replace that pattern?
Select an answer to reveal the explanation.
Short Explanation
Changing the roads and the tunnel maps on every block at once is how you get a city-wide outage. Canary a few leaves, validate routes and VTEPs, then roll—underlay and overlay both.
Full Explanation
Change windows that edit underlay BGP and overlay EVPN together across the whole civic fabric with no canary leaves maximize correlated outage risk. Replace that pattern with staged changes: limited canary devices, explicit validation of sessions, routes, and VTEP reachability, then progressive rollout. Separating blast radius for underlay versus overlay—and proving each stage on a few leaves first—is how professional municipal fabric operations absorb mistakes without taking down every agency workload at once.
Always rebooting every spine before any leaf change so overlays “reset cleanly” adds needless disruption and is not validation. Applying underlay and overlay commits simultaneously on all devices merely to keep timestamps identical maximizes blast radius by design. Skipping pre/post checks when Apstra is not in use is incorrect: manual fabrics still require structured validation gates.
Exam caveat: canary-and-validate beats fabric-wide dual-plane simultaneous commits whether or not a particular automation platform is present.
Operational check: choose canary leaves, apply underlay changes and verify BGP/ECMP, then apply overlay/EVPN changes and verify VTEP reachability plus a tenant test flow before expanding the same change set to the remaining civic pod.