SONiC
Module 5 · Open-Source SONiC vs Enterprise SONiC

Same Task, Two Distributions

75 minLabConfigurationOpen-sourceEnterprise

Perform the same set of equivalent tasks — configure an interface, add a VLAN, configure BGP, inspect a route, inspect hardware state, collect diagnostics — in both an open-source and an enterprise environment (where supported), then compare the workflow and the resulting visibility.

Safety: Caution

May change state — take a snapshot first.

Several commands here are disruptive — run them only in a change-safe, non-production environment.

Take a revertible snapshot before starting so cleanup is reliable.

Parallel task execution

Objective

  • Execute equivalent tasks in both environments and record the exact commands and workflow each requires.
  • Compare not just whether a task succeeds but what visibility each environment gives you into the result.
  • Identify where an enterprise distribution's tooling changes the workflow versus the base SONiC surface.

Starting state

  • Both environments reachable with a known-good baseline snapshot you can revert to.
  • A test interface/VLAN/BGP peering you are permitted to configure.

Prerequisites: Labs 5.1 complete. · Change-safe access to both environments (a non-production VS is ideal; treat any shared environment as caution).

Tasks

  1. 1

    Configure an interface

    SONiC CLI Disruptive
    sudo config interface ip add Ethernet4 10.5.2.1/31
    SONiC CLI
    show ip interfaces
    Expected:
    • The interface shows the configured address in both environments; note any CLI wording differences.

    What happened internally: Configuration writes to CONFIG_DB in both; the enterprise distribution may wrap or supplement the CLI but the underlying model is identical.

  2. 2

    Add a VLAN

    SONiC CLI Disruptive
    sudo config vlan add 100
    SONiC CLI
    show vlan brief
    Expected:
    • VLAN 100 present in both; compare the exact command and resulting show output.

    What happened internally: VLAN state flows CONFIG_DB → orchagents → SAI just as in Module 1; both distributions share this path.

  3. 3

    Configure BGP and inspect a route

    FRR / vtysh Disruptive
    vtysh -c 'configure terminal' -c 'router bgp 65005' -c 'neighbor 10.5.2.0 remote-as 65006'
    SONiC CLI
    show ip route bgp
    Expected:
    • The BGP session configuration is accepted; a learned route appears once the peer is up. Compare route-inspection commands across environments.

    What happened internally: Both distributions use FRR in the bgp container; the route-inspection experience should be very similar, which is itself a useful finding.

  4. 4

    Inspect hardware / ASIC state

    Observe how far the configured state reached toward hardware in each environment.

    SONiC DBIllustrative output
    redis-cli -n 1 KEYS 'ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY*'
    Expected:
    • Route entries visible in ASIC_DB on a real ASIC; on VS the ASIC layer is simulated — note the difference.

    What happened internally: This is the Module 1 'how far did it travel' check; hardware visibility may differ between VS and a real enterprise switch, which affects troubleshooting fidelity.

  5. 5

    Collect diagnostics in each environment

    SONiC CLIIllustrative outputdiagnostic bundle
    sudo show techsupport
    Expected:
    • A diagnostic bundle produced in each; compare contents and any vendor-specific additions.

    What happened internally: Diagnostic-bundle differences translate directly into TAC-case quality on the enterprise side.

Troubleshooting branches

If: A task is not supported in one environment

Then: Record it as a support-envelope finding; confirm against the distribution's feature statement rather than assuming a bug.

If: Config accepted but not reflected in hardware state

Then: Trace CONFIG_DB → APPL_DB → ASIC_DB per Module 1; on VS remember the ASIC layer is simulated.

Cleanup / rollback
  • Revert both environments to their baseline snapshot, or remove the test interface, VLAN, and BGP configuration.
  • Confirm no test configuration remains with show running-configuration (or the SONiC equivalent) before leaving.

Lab evidence checklist

  • Exact commands and workflow recorded for each task in both environments.
  • Visibility/observability of each result compared, not just success/failure.
  • Hardware/ASIC-state observation captured with the VS-vs-real caveat noted.
  • Diagnostic bundles collected and compared.

Reflection

  • Where did the enterprise distribution change the workflow, and where was it identical to the base SONiC surface?
  • Which tasks gave you better hardware visibility on a real enterprise switch than on VS, and how would that change your troubleshooting?
Lab notes & observations