Let’s now have a more detailed look at the system architecture of SONiC.
This diagram gives an overview of the architecture of SONiC and the interactions between the components, starting at the hardware level all the way up through the kernel and user space.
At the bottom of the diagram, we see elements which are related to the physical hardware, that is the switch running SONiC. Those are things such as fans, power supplies, or LEDs informing us about the status of each port. Two other crucial elements of each network device are the inserted modules and the switching ASIC.
All of the hardware elements have their respective drivers, which operate in the kernel space and enable communication between those hardware components and applications running in the user space. For example, the syncd container works with the ASIC driver residing in the kernel space to control and monitor the state of the switching ASIC. Other kernel drivers work in conjunction with daemons in the PMON container and, for example, make sure the switch does not overheat by reading values of the temperature sensors and controlling the speed of the hardware fans cooling the switch.
Moving one layer up, we enter the user space, which is where the actual SONiC subsystems reside. At the heart of it, we see the Redis server holding the databases crucial to the proper operation of SONiC. All of the SONiC containers interact with the various configuration and state databases running within the database container. In the following slides, we will go through each of the containers depicted on this diagram and explore in detail what their functions are.
Another critical piece is the SWSS, or Switch State Service, container. This container is responsible for relating events from various other subsystems and triggering dependent actions in other subsystems. For example, if an IP address is configured on an interface and that interface comes up, the IP subnet of the interface must be added to the routing and forwarding tables.
Apart from the containers already mentioned, we see a number of application containers that implement the actual networking functions: routing protocols in the BGP container, link aggregation in the teamd container, and other protocols or functions in their dedicated containers.
What is not shown here is the management framework container. This container is present in Enterprise SONiC by Broadcom, but not in the community edition or most other enterprise editions. We will talk about this container later.
Database container
Now, let’s see what all of these containers contribute to the operation of a switch running SONiC. We will start with the base subsystems that provide fundamental services to SONiC.
The first one is the database container running the Redis databases. These databases are the single source of truth for the complete switch state. They store information from all containers that is relevant to other containers. Normally, five database instances are running in this container.
The database labeled APPL_DB stores the state as generated by the application containers. This would include things like IP routes and their next hops, discovered neighbors, etc.
The CONFIG_DB, as the name suggests, stores the switch configuration.
The STATE_DB is probably the most sophisticated database. It stores the operational states that are possibly required to resolve dependencies between subsystems. This means that these states are relevant to multiple subsystems. For example, this would include things like the operational state of ports that are members of VLANs or have IP addresses configured.
The ASIC_DB is more or less a mirror of the ASIC state. It contains information to drive the configuration of the ASIC and also operational information read from the ASIC.
Finally, the COUNTERS_DB again does what the name suggests. It holds any kind of counters and statistics, for example, for interface usage, packet drops, access list hits, and so on.
SWSS container
The next base subsystem is the Switch State Service container, or SWSS for short. This one is responsible for the communication and arbitration between other containers.
It contains a number of *syncd processes that, as is typical in SONiC, listen to events occurring in the system. The processes in this container monitor events affecting port states, interface configuration, etc. They are publishers for the APPL_DB, which means that they write information about any such events to that database.
In contrast, the *mgrd series of processes are there to update the Linux kernel about such changes that relate to port or interface state or configuration. They are subscribers to the APPL_DB, the CONFIG_DB, and the STATE_DB, which means that they get notified about any changes in these databases and read the updated state.
Finally, there’s the orchagent process, short for orchestration agent, that extracts all the information from the APPL_DB and feeds it to the ASIC_DB so that the ASIC can eventually be programmed according to the application-level state. So this process is a subscriber to the APPL_DB and a publisher to the ASIC_DB.
syncd container
The last of the standard base subsystems is the syncd container. This is merely a link between the ASIC_DB database and the physical switching ASIC. It synchronizes the state between both in both directions, so it programs the ASIC with new table information available in the database and also updates the database with new state information read from the ASIC. The interaction with the ASIC happens through the Switch Abstraction Interface, SAI, that we have already heard about. Its implementation is able to program and monitor the ASIC.
Management framework container
The SONiC management framework container is a somewhat special container that is not found in every edition of SONiC. You could also consider it a base subsystem as it provides an interface to the switch configuration. It supplies an API that in turn provides access to the configuration resources and operational states of the switch.
It publishes configuration changes to the CONFIG_DB. To be able to retrieve configuration information or operational states, it subscribes to the CONFIG_DB and APPL_DB databases. The management framework API can be accessed in a number of ways, including the local management framework CLI, a RESTCONF server, or a gNMI server.
While this is not yet part of upstream SONiC, it is implemented in the Enterprise SONiC edition by Broadcom that we will discuss in this training. We will learn more about it in Module 3 of this training.
Application containers
The role of the application containers is quite easy to describe. Each of them implements a particular networking function or protocol. They all interact with the base subsystems as necessary. Today, we will find the following application containers in SONiC.
The BGP container runs an instance of Free Range Routing, FRR, to implement the complete routing stack. The name of the container is somewhat historic. Routing protocols other than BGP also run in this FRR instance and in this container. We will learn more about the routing stack and this container in Module 5.
The teamd container hosts the daemon with the same name and provides link aggregation functionality, or port channels as they are called in SONiC. We will learn more about these in Module 3.
The LLDP and SNMP containers obviously run the LLDP and SNMP protocols, respectively. LLDP is the Link Layer Discovery Protocol, which is useful to discover neighboring devices, and SNMP is the Simple Network Management Protocol that can be used to monitor the switch. We will learn more about these in Module 7.
The DHCP relay container hosts the corresponding function. It runs an instance of ISC DHCP Relay. We will learn more about DHCP relay in Module 5.
Finally, the PMON container is again something special. It is responsible for platform monitoring, as mentioned before, and contains daemons monitoring the thermal sensors, PSUs, inserted modules, etc., and also one to control the switch fans. We will learn more about this in Module 7.
You can also add containers of your own, which is something that makes SONiC unique. So it is quite easy to extend the functionality of SONiC to your needs.
