SonicLab18 lessons · Available
Learning path / Lesson 02
On this page
Foundations · 02 of 03

Architecture and Services

Locate the main services and learn where a routing decision crosses into forwarding orchestration.

Prerequisite: Introduction to SONiCConcept lesson · no running lab required
By the end, you should be able to:
  • Distinguish a container from the processes it hosts.
  • Assign clear roles to FRR, fpmsyncd, SWSS, and syncd.
  • Explain why a healthy container is only one health signal.
Scope: a common single-ASIC SONiC model. Release, image, platform, feature, and transport choices can change details. Commands and outputs here are teaching examples; no live SONiC behavior has been verified.

A Linux host with cooperating services

A container packages a service environment; a daemon is a running process. They are related but not interchangeable. For example, a routing container commonly named bgp hosts several processes, not just BGP. The Linux host also supplies kernel interfaces, service supervision, and management tools.

Container boundaries help organize the system, but state crosses those boundaries through databases, sockets, and kernel interfaces. Restarting one service can affect its dependents. Container names, enabled services, and process placement vary with image, release, and single- versus multi-ASIC designs.

Read further: SONiC architecture · SWSS component overview.

Who does what?

ComponentMain responsibility here
FRR / bgpdRuns BGP sessions, applies BGP policy and path selection, and supplies routes to zebra.
FRR / zebraManages routing information across protocol clients and forwarding updates; interfaces with the kernel and an FPM export path.
fpmsyncdReceives FPM forwarding updates and translates them into SONiC application route state on the conventional Redis path.
SWSS / orchagentConsumes relevant state, resolves object dependencies, and issues SAI operations. SWSS also includes other managers and synchronization daemons.
SAI Redis / syncdSAI Redis carries serialized operations across the process boundary. syncd invokes the vendor SAI implementation and handles related responses and notifications.
Platform and discovery servicesExamples include pmon for hardware monitoring and LLDP services for neighbor discovery; these serve different jobs from route programming.

Read further: FRR zebra documentation · FRR BGP documentation · fpmsyncd implementation · SAI Redis & syncd.

Follow responsibilities, not just containers

Common route-programming responsibilities
Common route-programming responsibilitiesA BGP peer sends updates to bgpd, which passes routes to zebra. Zebra exports forwarding updates through FPM to fpmsyncd. Application route state reaches orchagent, whose SAI operations cross SAI Redis and ASIC DB to syncd and vendor SAI, then hardware.BGP peerExternal neighborbgpdBGP policy / pathszebraRouting managerfpmsyncdFPM receiverFPMAPPL_DBRoute stateorchagentSAI operationsSAI Redis / ASIC_DBSerialized object operationssyncd / vendor SAIPlatform implementation / SDKASICForwarding stateLogical process path; not a packet path or a container-placement diagram.Other producers, consumers, responses, and kernel paths are omitted.
Original teaching diagram for a conventional Redis-based route path. Some releases and options use other transport paths, including ZMQ. Confirm the selected image rather than assuming one transport is universal.

FRR is a routing suite. fpmsyncd is a SONiC integration process: it does not run BGP best-path selection. Likewise, syncd does not replace zebra. Its job is at the SAI/platform boundary.

Read further: RouteSync implementation · syncd implementation.

Inspect a service without confusing layers

docker ps --format 'table {{.Names}}	{{.Status}}'
docker exec bgp vtysh -c 'show ip route'

Illustrative inspection commands, not executed. Docker access needs suitable privileges. Replace bgp with the actual routing container; FRR commands and namespaces vary by image.

The first command asks whether containers are running. The second asks FRR about routing state. A running container does not prove every daemon inside it is healthy. A route displayed by FRR does not by itself prove successful ASIC programming or packet delivery.

A useful fault question: if a route exists in FRR but is missing from the expected application route state, inspect the zebra-to-fpmsyncd integration and its logs before blaming the ASIC. First allow for convergence and verify the correct routing instance.

Read further: SONiC user manual · fpmsyncd implementation.

Key takeaways

  • A container is a service environment; it can contain several daemons.
  • bgpd handles BGP while zebra coordinates routing and forwarding updates.
  • fpmsyncd bridges FPM updates into SONiC route state on the common Redis path.
  • orchagent and syncd operate at different sides of the orchestration/SAI boundary.
  • Check process, routing, programming, and packet evidence separately.

Check your understanding

Six questions, four choices each. Check each answer for an explanation, then review your score and retry.

Official references

Reviewed 18 October 2026. Living upstream references describe several generations of SONiC; match operational details to the selected release. Implementation links support the examples, not a claim that every image runs current master.

Lesson 02 · Knowledge check