Module 5 · Open-Source SONiC vs Enterprise SONiC

Upgrade Planning Exercise

60 minLabConfigurationEnterpriseOpen-source

Build a complete, written upgrade plan for a SONiC switch: compatibility checks, configuration backup, image validation, maintenance-window design, redundancy handling, rollback strategy, and post-upgrade testing. This is a planning deliverable — you do not execute the upgrade.

Safety: Safe

Non-disruptive. Safe to run in the virtual lab.

This is a planning lab — do not run the upgrade or rollback commands against a real switch here.

The rollback command shown is illustrative and disruptive; it appears for the written plan only.

Upgrade plan stages

Objective

• Produce a written upgrade plan covering pre-checks, backup, validation, window, redundancy, rollback, and testing.
• Distinguish what an enterprise distribution supplies (supported tooling, documented paths) from what you must engineer on upstream.
• Make the rollback strategy explicit and tested-on-paper before any change.

Starting state

• A target switch/environment identified, current version recorded, and a desired target version chosen.
• Read-only access sufficient to gather pre-check evidence.

Prerequisites: Lessons 5.4–5.5 complete. · Access to (or documentation for) the target environment's upgrade tooling.

Tasks

1
Compatibility and pre-checks
Verify the target version supports your model/optics and record current health as a pre-upgrade baseline.
SONiC CLI
```
show version
```
SONiC CLIcurrent installed images (read-only)
```
sudo sonic-installer list
```
Expected:
- Current version, installed-image slots, and a compatibility statement (from the vendor matrix or upstream branch notes) recorded.
What happened internally: On enterprise, the compatibility matrix answers this directly; on upstream you assemble the answer yourself from branch/platform support.
2
Configuration backup
SONiC CLIpersist CONFIG_DB to config_db.json
```
sudo config save -y
```
Expected:
- config_db.json saved and copied off-box with a version/date label.
What happened internally: config_db.json is the SONiC backup artifact in both models; off-box, versioned copies are what make rollback real.
3
Image validation
State how the target image's integrity/authenticity is validated before install (signature/checksum) and its source.
Expected:
- A written validation step: source, checksum/signature method, and who is accountable for the image (vendor vs your build pipeline).
What happened internally: Enterprise images are vendor-signed; upstream images you build or fetch must be validated by your own process — a real difference in assurance.
4
Maintenance window and redundancy
Design the window: which device, redundancy/drain steps, blast radius, and warm-restart/HA considerations if applicable.
Expected:
- A window plan naming redundancy handling and expected dataplane impact.
What happened internally: Warm restart and HA support (Lesson 5.4 rows) determine whether the window can be non-disruptive — verify per distribution.
5
Rollback strategy
Write the explicit rollback: revert to the prior image slot and restore the saved config, with success criteria.
SONiC CLI DisruptiveIllustrative outputrollback step — do NOT run in this planning lab
```
sudo sonic-installer set-default <prior-image>
```
Expected:
- A step-by-step rollback with the exact prior version, config artifact, and go/no-go criteria — written, not executed.
What happened internally: Enterprise supplies a supported rollback procedure; on upstream you must have engineered and tested this path yourself beforehand.
6
Post-upgrade testing
Define the acceptance tests that confirm success: interfaces, routing/BGP, forwarding, and feature-specific checks.
Expected:
- A concrete post-upgrade test checklist with pass criteria mapped to the pre-upgrade baseline.
What happened internally: Comparing post-upgrade state to the pre-upgrade baseline is how you prove success rather than assume it.

Troubleshooting branches

If: No supported upgrade path documented for your version jump

Then: On enterprise, confirm the path in the vendor matrix; on upstream, this may require an intermediate version or local validation — record it as risk.

If: Rollback config may be incompatible with the prior image

Then: Verify the saved config_db.json is compatible with the rollback target; schema differences across versions can complicate restore.

Cleanup / rollback

None — this lab produces a written plan and gathers read-only evidence. Do not execute the upgrade or rollback.

Lab evidence checklist

☐ Compatibility/pre-check evidence and current baseline recorded.
☐ Off-box, versioned config backup created.
☐ Image validation step written with source and method.
☐ Maintenance-window and redundancy plan written.
☐ Explicit rollback procedure written (not executed).
☐ Post-upgrade test checklist with pass criteria written.

Reflection

Which plan steps did the enterprise distribution supply for you, and which would you have to engineer yourself on upstream?
Where is your plan most fragile, and what would you validate in a lab before touching production?

Lab notes & observations