What SONiC Is
SONiC 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.
Prerequisites: Comfort with a Linux shell · CCNP-level routing/switching background
Learning objectives
- →State what SONiC is and, just as importantly, what it is not.
- →Explain disaggregated switching and where SONiC sits versus IOS-XE, NX-OS, EOS, and Dell OS10.
- →Describe the relationship among SONiC, Linux, containers, SAI, and the ASIC.
- →Identify which of your existing skills transfer directly and which concepts are genuinely new.
Every troubleshooting instinct you have from a traditional NOS assumes one integrated system. SONiC breaks that assumption, and the wrong mental model sends you looking in the wrong place.
Once you see SONiC as a distributed system in one box, its logs, containers, and databases stop being noise and become the map.
What your CCNP already gives you
- • BGP, OSPF, VLANs, L2/L3 forwarding concepts — the networking is the same physics.
- • The idea of a RIB and a FIB, and that they are not the same thing.
- • EVPN/VXLAN control-plane vs data-plane separation.
- • Operational discipline: change control, backups, maintenance windows.
What is new in SONiC
- • State lives in databases (Redis) you can query directly, not hidden inside a single process.
- • Features are containers you can inspect, enter, and restart independently.
- • The ASIC is programmed through an open API (SAI), and you can observe the objects it creates.
- • The 'operating system' is ordinary Linux — systemd, docker, journald, /etc — underneath the switch.
| In the analogy | In SONiC |
|---|---|
| The front desk that accepts work orders | CLI / config tools |
| The work-order database | CONFIG_DB |
| The shared operational record every department reads | The Redis databases |
| Specialized departments and workers | Containers (bgp, swss, syncd, …) |
| The production coordinator | SWSS / orchagents |
| A universal machine-control language | SAI |
| The machine-specific driver | Vendor SDK |
| The high-speed production machinery | The ASIC |
| Items moving down the production line | Packets |
Where the analogy stops working
A factory's departments are physically separate; SONiC's containers share one Linux kernel, one CPU, and one set of hardware resources. And unlike a factory, some SONiC state is authored by protocols (BGP-learned routes) rather than arriving as a human 'work order' — so not everything starts at the front desk.
The one-sentence definition
SONiC (Software for Open Networking in the Cloud) is a Linux-based network operating system that runs its switching features as containerized microservices, stores state in a set of Redis databases, and programs merchant-silicon ASICs through the vendor-neutral SAI (Switch Abstraction Interface).
Read that again with a troubleshooting hat on: *Linux host*, *containers*, *databases*, *SAI*, *ASIC*. Those five words are five different places state can live — and five different places it can get stuck.
The SONiC stack, top to bottom
Disaggregated switching
Traditional switches ship as a single vendor stack: the NOS, the drivers, and the hardware are qualified and sold together. Disaggregation separates those layers so the network OS and the switch hardware can come from different places, connected by open interfaces.
SONiC is the OS layer of a disaggregated switch. Underneath it, merchant silicon (Broadcom, Marvell, Cisco Silicon One, and others) does the forwarding. Between them, SAI is the contract. This is why the same SONiC image concept can run on many hardware platforms — and why 'which ASIC?' is a first-class question in this course.
Do not stop at asking what is configured. Determine how far the intended state traveled through the system. Configuration in CONFIG_DB that never reached the ASIC does not forward a single packet.
Where SONiC fits versus what you know
| Concept | Cisco / Dell / traditional NOS | In SONiC |
|---|---|---|
| System model | One integrated NOS process/image (IOS-XE, NX-OS, EOS, OS10) | Linux host + independent containers + shared Redis state |
| Config store | Running-config held by the NOS | CONFIG_DB (Redis) as desired state, plus config_db.json on disk |
| Routing stack | Vendor routing process | FRRouting (zebra/bgpd) in the bgp container |
| Hardware programming | Proprietary vendor SDK, hidden | SAI (open API) via syncd, observable in ASIC_DB |
| Troubleshooting surface | show commands into one system | show commands + docker + redis-cli + Linux tools across layers |
What SONiC is not
It is not a hardware platform — it runs *on* platforms. It is not a single monolithic binary. It is not a magic layer that makes every ASIC behave identically. And it is not 'just Linux with some scripts' — the database-driven state model and SAI are the substance.
Common misconceptions
Myth: SONiC hides the ASIC like a traditional NOS.
Reality: SONiC exposes the path to the ASIC. You can watch SAI objects appear in ASIC_DB as you configure — the abstraction is observable, not hidden.
Myth: If the CLI accepted my config, the hardware is programmed.
Reality: The CLI writes desired state to a database. Programming happens asynchronously through several services. Acceptance is the beginning of the journey, not the end.
Myth: All SONiC builds are the same.
Reality: Versions and vendor distributions differ in features, database details, CLI, and defaults. Always note the version and distribution.
Go deeperWhy the cloud operators built it this way
Hyperscalers wanted to (a) buy switch hardware and software independently, (b) run the same operational tooling across many hardware vendors, and (c) fix and extend the NOS on their own schedule. A database-driven, containerized design gives them fault isolation, independent upgrades, and a clean automation surface — the same properties that make SONiC observable for you.
- When something is wrong, first decide *which layer* you are in: Linux host, a container, a database, SAI/syncd, or the ASIC.
- A 'show' command that reads from CONFIG_DB tells you intent; it does not confirm hardware state.
Key takeaways
- ✓SONiC = Linux host + containers + Redis databases + SAI + merchant ASIC.
- ✓It is a distributed system in one switch; diagnose it by following state between components.
- ✓Your networking knowledge transfers; the system model and troubleshooting surface are what's new.
- ✓Always record the SONiC version and distribution — behavior varies.
Tested against: SONiC 202305 / 202311 lineage · Upstream (community) unless noted · SONiC-VS (virtual) baseline · last reviewed 2026-07. Exact commands and behavior can vary by SONiC release, image, hardware platform, and enterprise distribution.
Knowledge check
In SONiC, where does an operator's interface configuration first land?
Order these layers from operator intent down to forwarding.
- 1APPL_DB
- 2ASIC forwarding
- 3SAI
- 4CONFIG_DB
- 5syncd → ASIC_DB
- 6SWSS / orchagents
Related lessons