EOS Upgrade Window With Mixed Cognitive Campus Platforms
A campus has 140 switches: 60 older fixed 1G/10G access switches, 50 newer Cognitive Campus access switches with PoE, and 30 distribution switches. All run EOS. The team wants to standardize on a single EOS release across the campus within one maintenance window. The distribution layer runs MLAG and BGP to the core. Access switches run MLAG to distribution pairs. The proposed target release is newer than what any device currently runs. Change policy allows a 4-hour window with rollback. The team has CloudVision managing all devices and a lab with two of each platform type.
1. Evaluate whether a single-window, single-release upgrade across all 140 devices is a sound plan. Identify the specific risks that make it unsound.
Read the worked answer
It is unsound as stated. Risks:
- Release support matrix: the target release may not support all three platform families, especially the older fixed switches. A single release across heterogeneous hardware assumes uniform support that must be verified per platform, not assumed.
- MLAG upgrade ordering: upgrading both MLAG peers simultaneously causes an outage. Peers must be upgraded one at a time with traffic drained or verified on the surviving peer, and the peer link/transit capacity checked (a single peer carrying all traffic can saturate).
- Distribution BGP: upgrading distribution devices can flap BGP sessions to the core; sequencing and graceful-restart behavior must be confirmed.
- 4-hour window: 140 devices with per-device reboot and verification cannot be safely validated in 4 hours, and a mid-window failure leaves a mixed-version state with limited rollback time.
- Lab coverage: two of each platform type is thin for PoE and MLAG interaction testing.
2. Propose a phased plan and the verification gates between phases.
Read the worked answer
Phase 0 - Pre-checks: confirm the target release is supported on every platform model (per release notes/support matrix); snapshot configs and CloudVision state; verify rollback images are staged. Gate: all platforms confirmed supported, or exclude unsupported models from the target release.
Phase 1 - Lab: upgrade the two-of-each lab devices, test MLAG failover, PoE behavior, and BGP graceful restart. Gate: no regressions; document expected post-upgrade state.
Phase 2 - Pilot: one MLAG pair in distribution and its access pairs, upgraded one peer at a time. Gate: MLAG stable, BGP sessions up, peer-link utilization acceptable, PoE devices powered.
Phase 3 - Rolling access waves: upgrade access switches in MLAG-aware batches (never both peers at once), verifying uplink redundancy. Gate: each wave healthy before the next.
Phase 4 - Remaining distribution pairs, one peer at a time. Gate: full BGP/MLAG verification.
Rollback: defined per phase with a time check; abort if the window budget is exceeded.