SONiC

Lab Environment

A hybrid model: a virtual lab that is your flight simulator, and — when available — physical switches that are the real aircraft.

Stage 1 — Virtual lab (the simulator)

A VMware/vCenter environment with SONiC-VS and Linux VMs. It offers snapshots, safe failure injection, fast rebuilding, and full Redis and container visibility. Repeatable and forgiving.

Stage 2 — Physical lab (the aircraft)

Dedicated physical SONiC switches in the data center. Real ASIC behavior, hardware counters, vendor SAI behavior, platform tools, enterprise distributions, and actual resource limits — none of which VS fully reproduces.

Initial virtual topology

Start small: one SONiC-VS, one Linux VM, one management network, one data network.

                  VMware vCenter

            Management Port Group
                 /            \
          SONiC VS           Linux Host

               Data Port Group
                 \            /
                  Direct Lab Link

Expanded virtual topology

For Modules 2 and 4, expand to two SONiC-VS and two Linux VMs with a SONiC-to-SONiC underlay.

Linux Host 1
     |
Host Network 1
     |
 SONiC VS 1
     |
Underlay Network
     |
 SONiC VS 2
     |
Host Network 2
     |
Linux Host 2

Suggested VM specifications

SONiC VS2–4 vCPU · 4–8 GB RAM · one management NIC · required data NICs. Disk per image requirements.
Linux host1–2 vCPU · 1–2 GB RAM · one management NIC · one data NIC.

Exact SONiC-VS requirements depend on the selected image — treat these as a starting point.

VMware considerations

  • Standard vs distributed port groups — either works; be consistent.
  • MAC address changes and forged transmits — may be required for SONiC data-plane interfaces to pass traffic.
  • Promiscuous mode — only where a lab genuinely needs it (e.g. certain capture scenarios); prefer the narrowest safe setting.
  • VLAN configuration and MTU — set MTU high enough for VXLAN overhead in Module 4.
  • Snapshot strategy — snapshot before each failure-injection lab.
  • VM NIC ordering — verify which vNIC maps to eth0 (management) vs EthernetN (front panel).
  • Mapping virtual NICs to SONiC interface names — record it in your inventory.
Narrowest safe setting

Do not blanket-enable every security setting. Enable promiscuous mode, forged transmits, or MAC changes only where a lab needs them, and prefer the most restrictive option that still works.

Lab inventory checklist

Record these once and reuse them across labs:

☐ vCenter name
☐ Cluster
☐ Datastore
☐ Management port group
☐ Data port groups
☐ SONiC image version
☐ Linux image version
☐ IP plan
☐ Physical switch vendor
☐ Physical switch model
☐ ASIC
☐ SONiC distribution
☐ Console access
☐ Out-of-band management access

Safety rules

Read before any failure-injection or physical lab
  • Never perform failure injection on production switches.
  • Use dedicated lab hardware.
  • Maintain console or out-of-band access.
  • Save and export configurations.
  • Verify reload and recovery procedures.
  • Record physical cabling.
  • Confirm maintenance authorization.
  • Understand that container restarts can have forwarding consequences.
  • Do not make direct Redis changes unless a lab explicitly instructs it.
  • Treat database editing as an advanced diagnostic exercise, not a routine configuration method.