SONiC

Module 1

SONiC Architecture & Operating Model

Stop seeing a monolith. Start seeing a distributed system in one switch.

~8 h3.5 h lecture4 h labs5 lessons5 labs10 check questions

Purpose

Teach the learner to stop viewing SONiC as a traditional monolithic network operating system and begin viewing it as a distributed system running inside one switch.

Establish the shared databases (Redis), containerized services, and the state-flow model that every later module depends on.

Learning objectives

  • →Explain what SONiC is and is not, and where it sits relative to IOS-XE, NX-OS, EOS, and Dell OS10.
  • →Navigate the Linux host that underpins the switch: shell, processes, services, logs.
  • →Map the major containers to their responsibilities and explain why service separation matters.
  • →Describe the core Redis databases (CONFIG_DB, APPL_DB, ASIC_DB, STATE_DB, COUNTERS_DB) and their roles.
  • →Trace configuration and state as they flow from operator intent toward hardware.

Lessons

  1. What SONiC IsSONiC is not a monolithic NOS with a hidden ASIC. It is a Linux host running containerized services that coordinate through shared Redis databases and program merchant silicon through SAI. This lesson reframes the mental model your CCNP gave you.45m
  2. Linux Under the SwitchUnderneath every SONiC container is an ordinary Linux host: systemd, docker, journald, /etc, and a management NIC. This lesson maps the host you already know onto the switch you are learning, and separates the host's own networking from the front-panel ports the ASIC owns.50m
  3. Containerized ServicesSONiC's features are separate containers — database, swss, syncd, bgp, teamd, lldp, pmon, snmp, telemetry, and more. This lesson gives each container a job description and explains why splitting the NOS into services changes how you upgrade, isolate faults, and troubleshoot.50m
  4. Redis and the SONiC DatabasesSONiC's services coordinate through a set of Redis databases — CONFIG_DB, APPL_DB, ASIC_DB, STATE_DB, COUNTERS_DB, and (on chassis) CHASSIS_APP_DB. This lesson gives each database a role in the desired/application/hardware/observed-state model, shows how to query them safely, and dispels the idea that ASIC_DB equals the hardware.55m
  5. Configuration and State FlowThis lesson traces intent end to end — operator → config interface → CONFIG_DB → managers → APPL_DB → SWSS orchagents → SAI → syncd → ASIC_DB → ASIC — and then shows the equally important path that does NOT start at CONFIG_DB: protocol-learned routes. Understanding both flows is what lets you localize a stall to a single hop.55m

Labs

  1. SONiC Virtual Switch BaselineStart a SONiC virtual switch, capture a baseline of version, platform, interfaces, and running containers, and save an initial snapshot you can return to.ObservationVirtualOpen-source45m
  2. Container ExplorationEnumerate 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.ObservationTroubleshootingVirtualOpen-source50m
  3. Redis ExplorationRead the SONiC database mapping, list the databases by name and id, query selected tables using targeted keys and SCAN, compare CONFIG_DB (intent) against STATE_DB (observed), then make one safe config change and watch exactly which keys move.ObservationCorrelationConfigurationVirtual55m
  4. Interface LifecycleFollow a single interface IP through the whole system: add it, find its CONFIG_DB entry, check the Linux netdev, verify application/hardware-facing state, then remove it and confirm every layer cleans up. One object, traced end to end.ConfigurationCorrelationVirtualOpen-source55m
  5. Build an Architecture MapA correlation capstone for Module 1: for a small set of objects, build a single map that connects command → database → service → Linux representation → hardware-facing state. You end the module holding the whole system in one table.CorrelationObservationVirtualOpen-source60m

Module summary

  • SONiC is a distributed system in one box: databases hold state, containers do work, and intent travels through layers you can observe.
  • The recurring discipline: do not stop at what is configured — determine how far the intended state traveled.

Completion checklist

  • ☐ I can list the core SONiC databases and say what each represents.
  • ☐ I can map each major container to its role and restart a non-critical one safely in the lab.
  • ☐ I can follow a configuration change from CLI to CONFIG_DB to application state.
  • ☐ I can explain why a protocol-learned route does not begin life in CONFIG_DB.
  • ☐ I built an architecture map connecting command, database, service, Linux, and hardware-facing state.
Carry this forward

Finish the labs before moving on — later modules assume you can navigate the databases and containers hands-on, not just in theory.