Module 5 · Open-Source SONiC vs Enterprise SONiC

Distribution Comparison Worksheet

60 minLabObservationOpen-sourceEnterprise

Systematically compare an open-source SONiC image against whatever enterprise SONiC environment you can access, across version, CLI, containers, databases, feature availability, logging, support bundles, upgrade commands, hardware visibility, and documentation quality. The deliverable is a completed worksheet, not a fixed 'right answer.'

Safety: Safe

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

Keep every command read-only; do not run upgrades or config changes in this lab.

Do not cite version-specific observations as durable facts — date them and note the exact versions.

Two environments, side by side

  Worksheet (your notes)
    │
    ├─ Open-source: SONiC-VS ── (build/version, CLI, containers, DBs)
    │
    └─ Enterprise: vendor SONiC ── (version, CLI, tooling, support bundle)

Objective

• Produce a dated, side-by-side comparison of two distributions across the worksheet dimensions.
• Distinguish cosmetic differences (CLI wording) from structural ones (feature support, tooling, support model).
• Practice recording 'not available' or 'unknown' as a finding rather than a blank.

Starting state

• An open-source SONiC-VS VM reachable and logged in.
• An enterprise SONiC switch/VM reachable if available; otherwise vendor documentation open.

Prerequisites: Lessons 5.1–5.3 complete. · Access to a SONiC-VS image and, where possible, an enterprise SONiC environment. If no enterprise environment is available, complete its columns from official vendor documentation and mark them 'from docs.'

Tasks

1
Record version, build, and platform for each environment
Anchor every later observation to the exact version and platform so the comparison is reproducible.
SONiC CLI
```
show version
```
SONiC CLI
```
show platform summary
```
Expected:
- Version string, build date/branch lineage, and platform/HWSKU recorded per environment.
What happened internally: Version and platform anchor everything else; different branch lineages explain many downstream differences you will observe.
2
Compare the CLI and containers
SONiC CLI
```
show feature status
```
Linux
```
docker ps
```
Expected:
- The set of enabled features and running containers per environment; note any vendor-specific containers or CLI additions.
What happened internally: Both are SONiC underneath, so the container model matches Modules 1–4; enterprise distributions may add vendor containers or CLI wrappers on top.
3
Inspect the databases
Confirm the Redis database model is present and note any differences in contents or access.
SONiC DBCONFIG_DB device metadata
```
redis-cli -n 4 KEYS 'DEVICE_METADATA|*'
```
Expected:
- Device metadata keys returned; the database-driven model is present in both.
What happened internally: The Redis DB model is core SONiC; observing it in both environments reinforces that enterprise value is around the base, not a different base.
4
Compare logging and support-bundle collection
Note the diagnostic/support-bundle command each environment provides and what it collects.
SONiC CLI
```
show logging
```
SONiC CLIIllustrative outputcollects a diagnostic bundle
```
sudo show techsupport
```
Expected:
- A techsupport/diagnostic bundle path per environment; note whether the enterprise distribution adds vendor-specific collection or a different bundle format.
What happened internally: Support-bundle tooling is what a TAC case is built on; differences here directly affect Day 2 escalation quality.
5
Record upgrade commands and hardware visibility
Capture the documented upgrade/install command and the platform/hardware visibility each provides. Do not execute an upgrade.
SONiC CLIinstalled images (read-only)
```
sudo sonic-installer list
```
SONiC CLIIllustrative output
```
show platform temperature
```
Expected:
- Installed-image list and available hardware/platform visibility recorded; note vendor diagnostics if present.
What happened internally: Upgrade tooling maturity and hardware diagnostics are Lesson 5.4 scorecard rows; this task feeds them with real observations.
6
Rate documentation quality
For one concrete task (e.g. 'configure a VLAN'), find the authoritative documentation in each environment and rate completeness, accuracy, and currency.
Expected:
- A short, dated documentation-quality note per environment.
What happened internally: Documentation is a scored criterion in Lesson 5.4; a real lookup exposes gaps that marketing claims hide.

Troubleshooting branches

If: A command is missing in one environment

Then: Command availability varies by image and distribution; record it as a finding and note the equivalent if one exists.

If: No enterprise environment is available

Then: Complete the enterprise columns from current official vendor documentation and clearly mark those cells 'from docs, dated.'

Cleanup / rollback

None — this is a read-only observation lab. Do not execute upgrades or disruptive commands.

Lab evidence checklist

☐ Version/build/platform recorded for both environments.
☐ CLI, container, and database observations captured.
☐ Logging and support-bundle behavior compared.
☐ Upgrade command and hardware visibility recorded (not executed).
☐ Documentation-quality note completed for both, dated.

Reflection

Which differences were cosmetic (CLI wording) and which were structural (feature support, tooling, support model)?
Which worksheet rows would you be unable to fill for upstream without the vendor doing the work — and what does that imply for staffing?

Lab notes & observations