Skip to content

0500-sonic-processes.md

Latest commit

 

History

History
266 lines (181 loc) · 8.29 KB

0500-sonic-processes.md

File metadata and controls

266 lines (181 loc) · 8.29 KB

5. SONiC Processes and Their Read/Write Responsibilities

SONiC consists of multiple containers, each containing one or more daemons. Communication between these daemons occurs through Redis and Linux netlink. Understanding which process reads or writes which Redis tables is essential for tracing system behavior and debugging.

This section groups processes by container and describes their roles, the tables they interact with, and how they drive configuration or state upward or downward through the system.

5.1 Management Plane Processes (mgmt-framework, config-engine)

The management plane processes implement user-facing interfaces:

  • CLI (config ...)
  • REST/RESTCONF
  • gNMI

These processes

  • Receive configuration from the user,
  • Validate and normalize inputs,
  • Write user intent into CONFIG_DB, and
  • Provide configuration to the users

mgmt-framework

This is the northbound management plane API in SONiC. It implements:

  • RESTCONF API
  • gNMI API
  • YANG-modeled configuration retrieval + updates
  • “show” commands via REST

mgmt-framework reads from CONFIG_DB when a user performs:

GET /restconf/data/sonic-vlan:sonic-vlan/VLAN_TABLE
gnmi-cli get /openconfig-interfaces:interfaces
show running-configuration
get-config over gNMI

config-engine

This component runs during:

  • Boot
  • config reload
  • config save
  • YANG-based template expansions

config-engine reads from CONFIG_DB to:

  • Build the running config or startup config JSON
  • Validate YANG constraints
  • Regenerate portions of the DB during reload
  • Apply templates for interfaces, VLANs, BGP, ACLs, etc.

Summary

Component Reads From Write To Purpose
mgmt-framework CONFIG_DB CONFIG_DB (via REST/gNMI edits) External API for config
config-engine CONFIG_DB, YANG Models CONFIG_DB Build/apply configuration

5.2 Control Plane Processes (bgp container — FRR)

The bgp container hosts the routing stack (FRR). It contains:

  • bgpd — BGP protocol engine
  • zebra — central RIB and FIB manager
  • staticd — static route manager

Responsibilities

  • Learn routes from BGP neighbors.
  • Maintain best-path selection.
  • Produce routes for SONiC’s data plane.

Internal Flow

bgpd → zebra → fpmsyncd → APPL_DB → orchagent

Key Points

  • Linux kernel routing table is not used for forwarding.
  • zebra sends routes using the FPM (Forwarding Plane Manager) socket.
  • fpmsyncd listens on the FPM socket and writes routes into APPL_DB.

5.3 swss container (*mgrd, *syncd processes)

SONiC’s architecture is built on a powerful separation of configuration intent, operational state, and hardware programming. In the center of this architecture sit two families of daemons:

  • *mgrd daemons
  • *syncd helper processes

5.3.1 *mgrd daemons - Translators of Configuration Intent

The purpose of the *mgrd daemons is simple but essential:

Take administrative intent from CONFIG_DB → apply it to Linux → express it for hardware via APPL_DB.

These daemons respond exclusively to configuration changes. If the admin changes the running configuration—whether through CLI, REST/gNMI, or config reload—the update first reaches CONFIG_DB. The *mgrd daemons wake up and translate that high-level intent into:

  • Linux network device creation
  • IP address assignments
  • VLAN and bridging configuration
  • VRF creation
  • Buffer profile computation
  • Static neighbor insertion

They also write APPL_DB entries that orchagent consumes to program SAI objects into hardware.

5.3.2 *syncd helper processes - Translators of Operational State

These processes sit on the opposite side of the architecture:

Take Linux operational/kernel/network/FPM state → publish it into APPL_DB → trigger hardware updates.

*syncd helpers listen to:

  • Netlink (interfaces, neighbor updates)
  • Kernel events
  • FRR Zebra’s FPM updates
  • ARP/NDP entries

They translate these physical events into APPL_DB entries that orchagent must react to.

5.3.3 APPL_DB isolation between *mgrd and *syncd

Both *mgrd and *syncd write to APPL_DB, but they write different fields for very different purposes.

Category Meaning Written By
Configuration fields What the admin wants *mgrd
Operational fields What the hardware/kernel reports *syncd

For example, in APPL_DB:PORT_TABLE:

  • Admin MTU / speed / FEC → portmgrd
  • Oper-up/down status → portsyncd

These sets of fields are non-overlapping, ensuring they never conflict.

5.3.4 Detailed breakdown of *mgrd daemons

vlanmgrd

  • Reads: CONFIG_DB:{VLAN_TABLE, VLAN_MEMBER_TABLE}
  • Writes: Linux bridge (via ip link, bridge vlan), APPL_DB VLAN tables
  • Purpose: Create VLANs and VLAN members in Linux, notify orchagent

portmgrd

  • Reads: CONFIG_DB:PORT_TABLE
  • Writes: Linux netdev attributes (MTU, speed, admin state), APPL_DB config fields
  • Purpose: Apply physical port configuration to Linux and orchagent

intfmgrd

  • Reads: Interface tables from CONFIG_DB
  • Writes: Linux IP address assignments, APPL_DB L3 interface tables
  • Purpose: Configure RIFs (router interfaces), VRF associations, IPs

neighmgrd

  • Reads: CONFIG_DB static neighbor entries
  • Writes: Linux ARP/NDP table
  • Purpose: Install static neighbors

vrfmgrd

  • Reads: CONFIG_DB VRF tables
  • Writes: Linux VRF devices, APPL_DB VRF_TABLE
  • Purpose: Create VRFs and notify orchagent

5.3.5 Detailed breakdown of *syncd helpers

portsyncd

  • Reads: Linux netlink (RTM_NEWLINK/DELLINK)
  • Writes: APPL_DB:PORT_TABLE (oper state), STATE_DB:PORT_TABLE
  • Purpose: Report physical link state to orchagent

intfsyncd

  • Reads: Linux netlink IP address updates
  • Writes: APPL_DB:INTERFACE_TABLE
  • Purpose: Notify orchagent when kernel gains/loses IPs

neighsyncd

  • Reads: Kernel ARP/NDP cache
  • Writes: APPL_DB:NEIGH_TABLE
  • Purpose: Publish dynamic neighbor events (ARP/NDP)

fpmsyncd

  • Reads: FRR Zebra via FPM (route updates)
  • Writes: APPL_DB:ROUTE_TABLE
  • Purpose: Reflect best routes from Zebra → orchagent for ASIC programming

5.3.6 orchagent (Core Orchestration Engine)

Runs in the swss container.

  • Reads CONFIG_DB, STATE_DB, and APPL_DB.
  • Determines required ASIC state.
  • Writes SAI operations to ASIC_DB.
Orchagent Reads From Writes To
orchagent CONFIG_DB, STATE_DB, APPL_DB ASIC_DB

5.6 syncd Container (SAI Execution Engine)

The syncd container hosts:

  • syncd daemon
  • SAI vendor library
  • ASIC SDK

Responsibilities

  • Apply SAI operations from ASIC_DB.
  • Poll ASIC counters and store them in COUNTERS_DB.
  • Emit hardware notifications (MAC learn, port state) to swss daemons.

Redis Interactions

Component Reads From Writes To
syncd daemon ASIC_DB COUNTERS_DB

5.7 Summary Table (Read/Write Matrix)

Process CONFIG_DB STATE_DB APPL_DB ASIC_DB COUNTERS_DB
mgmt-framework W - - - -
config-engine W - - - -
vlanmgrd R W - - -
portmgrd R W - - -
intfmgrd R W - - -
portsyncd - W - - -
neighsyncd - - W - -
fdbsyncd - - W - -
intfsyncd - W - - -
fpmsyncd - - W - -
orchagent R R R W -
syncd daemon - - - R W