Module 1 · SONiC Architecture & Operating Model

Container Exploration

50 minLabObservationTroubleshootingVirtualOpen-source

Enumerate the running SONiC containers, map each to its role, enter selected containers to use their native tooling, read their logs, then restart a NON-critical service in the virtual lab and watch systemd bring it back.

Safety: Caution

May change state — take a snapshot first.

NEVER restart swss, syncd, or database in this lab — they are disruptive to the data plane and/or wipe shared state.

Restart only after noting how to revert (baseline snapshot).

Single-node container view

  SONiC-VS host (Linux)
    └─ docker
        ├─ database   ├─ swss   ├─ syncd   ├─ bgp
        ├─ teamd      ├─ lldp   ├─ pmon    ├─ snmp   └─ telemetry

Objective

• Produce a container→role map for this specific image.
• Practice entering a container and reading its logs.
• Observe systemd-supervised recovery of a non-critical service without disrupting forwarding.

Starting state

• SONiC-VS powered on and reachable; you are at the host bash shell.
• Baseline snapshot available in vCenter.

Prerequisites: Lessons 1.2 and 1.3 complete. · The 'baseline' snapshot from Lab 1.1 exists (so you can revert if needed).

Tasks

1
Enumerate running containers
Linux
```
docker ps --format 'table {{.Names}}\t{{.Status}}'
```
SONiC CLI
```
show feature status
```
Expected:
- A list of containers with uptime; feature status showing which features are enabled.
What happened internally: docker ps reads the docker daemon; show feature status reads CONFIG_DB/STATE_DB FEATURE tables. A feature can be disabled (no container) yet not be a fault.
2
Build the container→role map
For each running container, write down its responsibility from Lesson 1.3. Flag which are critical (database, swss, syncd) and which are non-critical (lldp, snmp, telemetry).
Expected:
- A table you author mapping every running container to a one-line role and a criticality label.
What happened internally: This map is what turns a symptom into an owner container later. Criticality determines what is safe to restart.
3
Enter a container and use its native tooling
Enter the bgp container and drop into FRR's shell; enter the swss container and list its processes. Exit with exit (this does not stop the container).
LinuxFRR tooling inside the bgp container
```
docker exec -it bgp vtysh -c 'show ip bgp summary'
```
Linux
```
docker exec -it swss ps -ef
```
Expected:
- FRR responds from inside bgp; swss shows orchagent and related processes.
What happened internally: Each container carries its own userspace and tools. docker exec attaches to a running container; exiting the shell leaves the daemon running.
4
Inspect logs at both layers
Linux
```
sudo journalctl -u lldp --no-pager | tail -n 20
```
Linux
```
docker logs --tail 20 lldp
```
SONiC CLI
```
show logging | tail -n 20
```
Expected:
- Host-journal entries for the unit, the container's own log tail, and the syslog view — three correlated windows on the same service.
What happened internally: SONiC logging is layered: journald/rsyslog on the host plus per-container logs. Correlating them is how you confirm a daemon actually converged.
5
Restart a NON-critical service and observe recovery
Choose a non-critical service (lldp is a good choice). Note the container's start time, restart it, and confirm systemd/docker brings it back. Do NOT restart swss, syncd, or database in this lab.
Linuxnon-critical: neighbor discovery only
```
sudo systemctl restart lldp
```
Linux
```
docker ps --filter name=lldp --format '{{.Names}} {{.Status}}'
```
Expected:
- lldp briefly disappears/restarts, then shows a fresh uptime; forwarding and management are unaffected.
What happened internally: systemd supervises the container lifecycle. Restarting lldp only interrupts neighbor discovery; the data plane (owned by syncd/ASIC) is untouched — a concrete demonstration of fault isolation.

Troubleshooting branches

If: docker exec fails with 'container not running'

Then: Confirm the feature is enabled and the container is Up (show feature status, docker ps).

If: Service does not come back after restart

Then: Check systemctl status <unit> and journalctl -u <unit> for the failure reason; revert to the baseline snapshot if needed.

Cleanup / rollback

Confirm the restarted service is Up and healthy.
No config was changed; if anything looks off, revert to the 'baseline' snapshot.

Lab evidence checklist

☐ Container→role map authored with criticality labels.
☐ Evidence of entering at least two containers and using native tooling.
☐ Three-layer log capture (journal, container, syslog) for one service.
☐ Before/after container status showing the non-critical restart and recovery.

Reflection

Why was it safe to restart lldp but not syncd? What is the blast radius of each?
You saw the container 'Up' after restart — what additional evidence tells you the daemon actually converged?

Lab notes & observations