SONiC system architecture

The SONiC system consists of two parts:
1. Modules
that interact with each other 2. Infrastructure for interaction (centralized, scalable)

The infrastructure used for interaction is mainly a non-relational database Redis engine:
1. Provides an interface that ignores language
2. It is a means of data retention, replication and multi-process interaction

Each module only subscribes to the data it cares about

Each module exists in its own Docker container to form an independent component, and each component is completely decoupled from platform details

SONiC consists of the following containers:

• Dhcp-relay
• Pmon
• Snmp
• Lldp
• Bgp
• Teamd
• Database
• Swss
• Syncd

The following figure depicts the functions contained in each module and the interaction between them.
Not all functions interact with the Redis server, and some of them interact with external entities (netlink, file system, etc.).
The blue arrow in the figure indicates the interaction with the Redis database, and the black transaction indicates the interaction with external entities

Not all functions are located in a container, such as CLI and sonic configuration module, is located on the Linux host

SONiC subsystem description

Teamd container:

Pmon container:

Snmp container:

Dhcp-relay container:

Lldp container:

Bgp container:

Can run Quagga or FRR routing protocol stack
This container can be further divided into the following parts:

• bgpd:
  Obtain the routing status and send it to the forwarding plane through the zebra and fpmsyncd interfaces
• zebra:
  is a routing manager. It provides routing table update, interface query, and routing distribution between different protocols.
  At the same time, it will deliver the calculated FIB to the kernel (via netlink) and the southbound forwarding process component (via Forwarding-Plane-Manager interface, or FPM)
• fpmsyncd:
  A little daemon. Mainly responsible for injecting the FIB state collected from zebra into the APPL_DB table in the Redis engine

Database container:

Swss container:

SWitch State Service is a set of tools, which can effectively promote the communication between the various modules of SONiC.
It provides a mechanism to facilitate multi-party communication and arbitration.

At the same time, several processes of SWSS will be responsible for the northbound interaction with the SONiC application layer.
Three of them are running in other containers, including Fpmsyncd, Teamsyncd and Lldp_syncd,
but no matter which container they are running in, they have a common goal:
[
Provide the means to allow connectivity between SONiC applications and SONiC's centralized message infrastructure (redis-engine).] [provide the means to allow connectivity between SONiC applications and SONiC's centralized message infrastructure (redis-engine).]
These processes are customary Name it *syncd. Here are the various syncd:

• Portsyncd
  listens for port-related netlink events. During startup, portsyncd will obtain physical port information by parsing the hardware configuration file of the system.
  Finally portsyncd pushes all collected status information to APPL_DB. Like port rate, lanes and MTU will be transmitted through this channel.
  portsyncd will also inject state into STATE_DB.
• Intfsyncd
  monitors interface-related netlink events and pushes the collected status information to APPL_DB. Parameters like the newly created/modified interface IP address will be processed through this process.
• Neighsyncd
  monitors neighbor-related netlink events, which are usually triggered by the ARP processing process generated by newly discovered neighbors.
  Information such as MAC addresses and neighbor address family information are processed through this process. For the purpose of L2 rewriting of the data plane, finally this state information will be used to construct the adjacency list. Again, this status information will eventually be transferred to APPL_DB.
• Teamsyncd runs
  in the teamd container, and the status information it obtains will be transmitted to APPL_DB.
• Fpmsyncd runs
  in the bgpd container, and the status information it obtains will be transmitted to APPL_DB.
• Lldp_syncd runs
  in the lldp container.

The above processes are all publishers. According to the publisher/subscriber model, SWSS also needs the role of subscriber to complete the consumption and transfer of received messages. The following processes are such roles:

• Orchagent
  is the most important component of the SWSS subsystem. Orchagent contains a logical processing function to extract all the state information injected from other *syncd processes, then process and forward the information, and finally push the information to the southbound interface of Orchagent . This southbound interface is the ASIC_DB in the redis engine, so we can find that Orchagent is both a subscriber and a producer, because it not only obtains data from APPL_DB, but also provides data to ASIC_DB.
• IntfMgrd
  processes the state information from APPL_DB, CONFIG_DB and STATE_DB, and then configures the interface information in the Linux kernel. This step will only be performed if there is no conflicting or inconsistent data in any of the detected databases.
• VlanMgrd
  processes the state information from APPL_DB, CONFIG_DB and STATE_DB, and then configures the vlan interface information in the Linux kernel. Just like IntfMgrd, this step is only executed if there is no conflicting data.

Syncd container:

The main goal of Syncd is to provide a mechanism that allows the switch's network status information to be synchronized with the actual status of the switch hardware/ASIC. This mechanism mainly includes initialization, configuration, and collection of the current state of the switch ASIC.

It contains several main logic modules:

• Syncd:
  Syncd implements the synchronization mechanism mentioned above. When compiling, syncd connects with the ASIC SDK provided by the hardware vendor and injects the status information into the ASIC. This effect is achieved by referencing the provided interface. Syncd subscribes to ASIC_DB information, obtains information from SWSS, and at the same time registers itself as a producer, and publishes the status information obtained from the hardware.
• SAI API:
  SAI (Switch Abstraction Interface) defines an API that provides a vendor-independent way to control the forwarding unit, such as a switch ASIC, which is a unified NPU or a soft switch.
• ASIC SDK:
  Hardware vendors expect to provide a SAI-friendly SDK implementation method that can drive their ASIC. This implementation is usually implemented in the form of a dynamic-linked-library. This mechanism calls the driver (here, syncd) to execute its driver.

CLI / sonic-cfggen:

SONiC is responsible for providing functional modules for command line and system configuration.
CLI components rely heavily on Python's Click library, which provides users with a flexible and customized way to build a command-line tool.

The Sonic-cfggen component is called by SONIC CLI to complete configuration modification and any configuration related actions that interact with the SONiC module.

Interaction of SONiC subsystem

Route status interaction

In this part, let's take a look at the processing flow of SONiC when an eBGP routing update is received. We assume that the session has been established, and the new route learned has its direct connection port as the next hop.

The following figure shows the processing flow, some unnecessary steps have been omitted:

(0) When the BGP container is initialized, zebra connects to fpmsyncd through a regular TCP socket. In a stable state, the routing table held by zebra, the Linux kernel, APPL_DB and ASIC_DB need to be highly consistent.

(1) A new TCP packet arrives at the BGP bit in the kernel space. The kernel's network stack will finally deliver the carried load to the bgpd process.

(2) Bgpd parses the new data packet, processes the bgp update, and informs zebra of the existence of the new prefix and the next hop related to the protocol.

(3) According to zebra's reachability judgment, zebra generates a route-netlink status information and injects it into the kernel.

(4) Zebra uses the FPM interface to send this netlink-route message to fpmsyncd.

(5) Fpmsyncd processes the netlink message and then pushes the message to APPL_DB.

(6) As a subscriber who subscribes to APPL_DB, orchagentd will receive the information content previously pushed to APPL_DB.

(7) After completing the processing of the received information, orchagentd will reference the sairedis APIs to complete the injection of routing information to the ASIC_DB.

(8) As a subscriber who subscribes to ASIC_DB, syncd will receive the new status information generated by orchagentd.

(9) Syncd will process the information, then reference SAI APIs, and inject this status information into the corresponding asic driver.

(10) Finally, the new routing information is pushed to the hardware.