Module 1 · SONiC Architecture & Operating Model

SONiC Virtual Switch Baseline

45 minLabObservationVirtualOpen-source

Start a SONiC virtual switch, capture a baseline of version, platform, interfaces, and running containers, and save an initial snapshot you can return to.

Safety: Safe

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

Command availability can vary by image and distribution — do not assume a missing command means a broken system.

Single-node baseline

  VMware vCenter
    │
    ├─ Management port group ── SONiC-VS (eth0 = mgmt)
    │
    └─ (front-panel NICs map to Ethernet0, Ethernet4, …)

Objective

• Establish a known-good baseline of the virtual switch.
• Learn to read version, platform, interface, and container state.
• Create a snapshot so later labs (including failure injection) can be rolled back.

Starting state

• SONiC-VS powered on, management reachable, default credentials in use per your lab.
• You are logged into the SONiC CLI (admin shell).

Prerequisites: Lesson 1.1 complete. · A SONiC-VS VM reachable over its management IP (see the Lab Environment page).

Tasks

1
Record version and platform
Capture the exact image version and platform so every later observation is anchored to it.
SONiC CLI
```
show version
```
SONiC CLI
```
show platform summary
```
Expected:
- A version string, build date, and platform/HWSKU identifying the (virtual) platform.
What happened internally: These read from STATE_DB / device metadata populated at boot. On SONiC-VS the 'platform' is a virtual one — a reminder that VS does not reproduce real ASIC behavior.
2
Inventory interfaces
SONiC CLI
```
show interfaces status
```
SONiC CLI
```
show ip interfaces
```
Expected:
- Front-panel interfaces named EthernetN with admin/oper state; the management interface separate from data ports.
What happened internally: Interface oper/admin state is reflected across CONFIG_DB (intent) and STATE_DB/APPL_DB (observed/applied). You are seeing the top of a stack you will trace later.
3
List running containers and failed services
Linux
```
docker ps
```
Linux
```
sudo systemctl --failed
```
Expected:
- Containers such as database, swss, syncd, bgp, teamd, lldp, pmon, snmp, telemetry (set varies by image).
- Ideally no failed systemd units.
What happened internally: Each feature is a container; systemd supervises them. A failed unit here is your earliest signal that a whole subsystem is down.
4
Save configuration and take a snapshot
Persist the running configuration, then take a VM snapshot in vCenter labeled 'baseline'.
SONiC CLIwrites config_db.json
```
sudo config save -y
```
Expected:
- config_db.json updated; a vCenter snapshot you can revert to.
What happened internally: config save serializes CONFIG_DB to /etc/sonic/config_db.json so it survives reboot. The VM snapshot captures everything else (containers, STATE_DB) for fast rollback.

Troubleshooting branches

If: A command is not found

Then: Command availability varies by image/distribution; check show ? and the Command Reference. Note the difference in your lab log.

If: A container is missing from docker ps

Then: Confirm the feature is enabled (show feature status); some features are off by default on VS.

Cleanup / rollback

None required — this is an observation lab. Keep the 'baseline' snapshot; later labs revert to it.

Lab evidence checklist

☐ Version + platform captured.
☐ Interface list captured.
☐ Container list captured.
☐ config saved and a 'baseline' snapshot exists.

Reflection

Which outputs described *intent*, and which described *observed/applied* state?
If a front-panel interface showed 'up' here, what have you actually confirmed — and what have you not yet confirmed about forwarding?

Lab notes & observations