Containerized Services
SONiC'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.
Prerequisites: Lesson 1.2 complete. · Understanding that the host is Linux running docker.
Learning objectives
- →Name the major SONiC containers and state each one's responsibility.
- →Explain why swss and syncd are distinct, and what SAI sits between them.
- →Reason about the operational consequences of service separation: fault isolation, upgrades, and state sync.
- →Recognize that the exact container set is image-, platform-, and vendor-dependent.
Knowing which container owns a symptom is half the battle: a BGP problem lives in the bgp container, a hardware-programming stall lives in syncd, a sensor alarm lives in pmon.
Service separation is why you can restart or upgrade one feature without rebooting the switch — and why a single crash-looping container can silently degrade one plane while everything else looks healthy.
What your CCNP already gives you
- • The role of a routing daemon (you know FRR-style zebra/bgpd from many NOSes).
- • LACP/port-channel concepts (teamd implements the same LACP you already run).
- • LLDP, SNMP, and streaming telemetry as operational services.
What is new in SONiC
- • Those services are independently deployable containers, not modules of one image.
- • The translation from intent to hardware is split across two services (swss and syncd) with SAI between them.
- • You can enter a container and troubleshoot the daemon inside it directly.
- • Fault isolation and per-service upgrade are first-class, and so is the complexity of coordinating many services.
| In the analogy | In SONiC |
|---|---|
| The central records room every department consults | database (redis) |
| The production coordinator translating orders into machine work | swss / orchagents |
| The operator who actually drives the machinery | syncd |
| The logistics/routing department negotiating with partners | bgp (FRR) |
| The team that bonds multiple docks into one (LACP) | teamd |
| The reception desk exchanging badges with neighbors | lldp |
| Facilities monitoring: temperature, fans, power, optics | pmon |
| The reporting office publishing status to headquarters | snmp / telemetry |
Where the analogy stops working
Real departments are independent; these containers are tightly coupled through shared state and ordering. If the database container is unhealthy, everything that reads it degrades at once — the 'departments' share a single records room and a single kernel, so isolation is real but not absolute. And syncd is not generic: it embeds vendor-specific SAI + SDK, so it is the least portable 'department' of all.
The NOS as a set of services
Instead of one image that owns routing, interfaces, LACP, and hardware, SONiC runs each as a container with a narrow job. They coordinate through the Redis databases (Lesson 1.4). This is the single most important structural fact about SONiC operations: there is no monolith to grep — there is a set of services, and state passing between them.
Major containers and their responsibilities
| Container | Responsibility | Criticality | If it is down… |
|---|---|---|---|
| database | Hosts the Redis instance(s) holding all SONiC DBs. | Critical | Nearly everything degrades — the shared state store is gone. |
| swss | Switch State Service: orchagents translate APPL_DB intent into SAI objects. | Critical | New intent stops reaching hardware; existing forwarding may persist. |
| syncd | Pushes SAI objects to the ASIC via the vendor SDK; owns ASIC_DB. | Critical (vendor-specific) | Hardware programming stops; the data plane cannot be changed. |
| bgp | FRRouting (zebra/bgpd); computes routes and feeds them to the DB. | High | Routing control plane is down; learned routes age out. |
| teamd | LACP / port-channel (LAG) management. | High | LAGs cannot negotiate; bundles may go down. |
| lldp | Neighbor discovery via LLDP. | Low | Neighbor visibility lost; forwarding unaffected. |
| pmon | Platform monitor: fans, PSUs, temperature, transceivers. | Medium | You lose sensor/optics visibility and alarms. |
| snmp | SNMP agent for legacy monitoring. | Low | SNMP polling fails; device keeps forwarding. |
| telemetry | Streaming telemetry (gNMI/gNOI). | Low | Streaming stops; device keeps forwarding. |
swss decides *what* SAI objects should exist (orchagents, reading APPL_DB). syncd makes them *real* in silicon (calling the vendor SAI/SDK, reflected in ASIC_DB). SAI is the contract between them. When intent does not reach hardware, the stall is almost always in this swss→SAI→syncd handoff — which is why Lesson 1.5 traces it end to end.
Why service separation matters operationally
Fault isolation: a crash in lldp or snmp does not touch forwarding. The blast radius of a bug is scoped to its container — usually.
Independent upgrades: a container can be replaced/upgraded without rebooting the switch, enabling targeted fixes and warm/fast reboot patterns (feature-dependent).
Troubleshooting: you can docker exec into the exact service and use its native tools (for example vtysh inside bgp), instead of one giant log.
State sync: because services coordinate through Redis rather than direct calls, you can *observe* the coordination — the DB is a debugging surface, not a black box.
Operational complexity (the tradeoff): more moving parts, ordering dependencies, and version-skew concerns. A healthy docker ps is necessary but not sufficient; a container can be *up* yet its daemon wedged.
Restarting lldp, snmp, or telemetry in a lab is low-risk. Restarting swss, syncd, or database is disruptive — it can flap the data plane or wipe/rebuild state. Know the criticality before you touch a service. (Lab 1.2 restarts only a non-critical service on purpose.)
Common misconceptions
Myth: Every SONiC device runs the same containers.
Reality: The container set depends on image, platform, enabled features, and vendor distribution. Always confirm with docker ps / show feature status.
Myth: syncd is a generic, vendor-neutral service.
Reality: syncd embeds the vendor's SAI implementation and SDK. It is the most hardware- and vendor-specific container in the system.
Myth: If a container shows Up in docker ps, the feature is working.
Reality: 'Up' means the container is running, not that the daemon inside is healthy or has converged. Verify via logs and the databases.
Go deepergbsyncd, chassis, and the multi-ASIC wrinkle
On platforms with a gearbox/PHY, a gbsyncd container programs the gearbox in parallel with syncd. On multi-ASIC and modular chassis, several instances of swss/syncd/database run — one per ASIC — and an additional CHASSIS_APP_DB coordinates across line cards. The single-container mental model still holds; there are simply *more* of them, and 'which ASIC/namespace?' becomes part of every question.
- Map the symptom to an owner container first: routing→bgp, hardware programming→syncd, sensors→pmon, LAG→teamd.
- Treat
docker psUp as necessary-not-sufficient; confirm the daemon inside converged via its logs/DB. - Restart critical containers (swss/syncd/database) only with intent — they are disruptive to the data plane.
Key takeaways
- ✓Features are independent containers coordinating through Redis, not modules of one binary.
- ✓swss (decide SAI objects) and syncd (program the ASIC) are two halves joined by SAI.
- ✓Separation buys fault isolation and per-service upgrades at the cost of more moving parts.
- ✓The container set is image/platform/vendor-dependent; syncd is the most vendor-specific.
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
Select all that apply.
Which of the following are genuine operational benefits of SONiC's containerized service separation?
Match each SONiC container to its primary responsibility.
Related lessons