Module 5 · Open-Source SONiC vs Enterprise SONiC

Troubleshooting Experience Comparison

75 minLabFailure injectionTroubleshootingOpen-sourceEnterprise

Introduce the same conceptual failure — for example, a shut interface or a mis-set BGP neighbor — into both an open-source and an enterprise environment, then compare detection, logs, the diagnostic commands available, the root-cause workflow, recovery, documentation, and the support/escalation path.

Safety: Caution

May change state — take a snapshot first.

Fault injection is disruptive — only in a non-production, revertible environment.

Do not open a real vendor support case as part of this exercise.

Same fault, two environments

  Inject identical conceptual fault
    │
    ├─ Open-source: detect → logs → diagnose → recover (self / community)
    │
    └─ Enterprise:  detect → logs → diagnose → recover (+ TAC path)

Objective

• Compare the end-to-end troubleshooting experience for one identical fault across both models.
• Evaluate the escalation/support path difference concretely, not abstractly.
• Confirm that the SONiC diagnostic surface (Modules 1–4) is the same underneath, and identify what the enterprise model adds.

Starting state

• Both environments healthy at a known baseline with a working test path (interface/BGP up).
• A revertible snapshot in each environment.

Prerequisites: Modules 1–4 troubleshooting content and Lab 5.2 complete. · Change-safe access to both environments with revertible snapshots.

Tasks

1
Inject the same conceptual fault in both environments
Choose one fault and apply it identically — e.g. administratively shut the test interface, or configure a wrong BGP remote-as. Do not stack multiple faults.
SONiC CLI Disruptiveexample injected fault
```
sudo config interface shutdown Ethernet4
```
Expected:
- The test path breaks identically in both environments.
What happened internally: Injecting an identical fault isolates the variable to the *troubleshooting experience*, not the fault itself.
2
Compare detection and logs
SONiC CLI
```
show interfaces status
```
SONiC CLI
```
show logging
```
Expected:
- Down state and relevant log entries visible in both; note any richer/vendor-specific logging on the enterprise side.
What happened internally: The base log/state surface is shared SONiC; enterprise distributions may add correlation, formatting, or vendor logs.
3
Walk the root-cause workflow
Use the Module 1 layered approach: intent (CONFIG_DB) vs applied (APPL_DB/STATE_DB) vs hardware (ASIC_DB).
SONiC DBIllustrative output
```
redis-cli -n 4 HGETALL 'PORT|Ethernet4'
```
Expected:
- The admin_status field reveals the injected shut; the workflow is identical in both environments.
What happened internally: This demonstrates the key point: the diagnostic *method* is SONiC's and transfers across distributions.
4
Recover and confirm
SONiC CLI Disruptive
```
sudo config interface startup Ethernet4
```
SONiC CLI
```
show interfaces status
```
Expected:
- The test path recovers in both environments.
What happened internally: Recovery uses the same SONiC surface; note whether the enterprise distribution offers additional guided-recovery tooling.
5
Compare documentation and escalation path
For this fault, locate the troubleshooting documentation in each environment and identify the support/escalation path: community/self-support (upstream) versus TAC-with-SLA (enterprise). Do NOT open a real support case.
Expected:
- A short comparison of documentation quality and a clear statement of the escalation path available in each model.
What happened internally: This is the decisive Day 2 difference from Lesson 5.5 — same diagnosis, very different backstop when you are stuck.

Troubleshooting branches

If: The fault behaves differently in the two environments

Then: Confirm you injected an identical conceptual fault; VS simulates hardware, so ASIC-level symptoms may differ from a real switch.

If: You cannot find troubleshooting docs for upstream

Then: That absence is itself a finding — record it against the documentation and support rows of the Lesson 5.4 scorecard.

Cleanup / rollback

Revert both environments to baseline or confirm the test path is fully restored.
Ensure no injected fault remains before leaving.

Lab evidence checklist

☐ Identical fault injected in both environments.
☐ Detection, logs, root-cause workflow, and recovery captured for each.
☐ Documentation quality compared.
☐ Escalation/support path for each model clearly stated (no real case opened).

Reflection

How much of the diagnosis was identical across distributions, and what does that tell you about where enterprise value actually sits?
When you got stuck, what would happen next in each model — and how does that map to your team's real support capacity?

Lab notes & observations