In the previous lesson, we have heard that SONiC is an open source project, and naturally it also leverages several other open source projects as a foundation to build a reliable and scalable network operating system. Let us have a look at the most important projects that serve as building blocks for SONiC.
It is worth emphasizing that SONiC hasn’t been built from scratch. It uses several renowned open source projects that serve as a reliable base for SONiC.
The solid foundation for all of this is certainly the Linux operating system that provides a robust, scalable, and versatile infrastructure for a SONiC system. Linux has been around for decades and is probably one of the most reliable base operating systems that you could use as a foundation, and it comes for free too. SONiC is based on the Debian distribution, which among all Linux distributions, is again renowned for its stability.
In the previous lesson, we have heard that SONiC features a modular containerized architecture. This is implemented with the help of Docker containers. Docker is the most popular implementation of containers, building on top of the Linux kernel.
The Linux kernel itself and the ecosystem around it already supply a wealth of networking-related projects that SONiC can use without having to reinvent the wheel in several places.
Also, SONiC uses Redis databases to implement a single source of truth of the complete switch state.
One of the most distinctive features of SONiC is the abstraction of the switching ASIC, which makes it easy to port SONiC to new systems. This is done with the help of the Switch Abstraction Interface, SAI, that provides a uniform API to all ASIC functions.
Finally, SONiC, of course, has added a lot more functionality, which would, among other things, affect the management of the system and specific functions like MCLAG that we will learn about in a later module. We will meet a lot of these throughout this training.
Linux
Taking a closer look at Linux as the SONiC base, we can recall several attributes which Linux is known for. First of all, we know it as a very reliable operating system, and SONiC can certainly build on that. Linux is open, so it is easily accessible as a foundation. SONiC will also draw on Linux’s scalability when it comes to operating very large networks. Regarding modularity, we should, of course, mention the use of containers, but it also means that SONiC needs to use only the pieces of Linux that it requires, reducing its footprint. Linux already comes with a lot of network-related functions that SONiC can leverage, both in the kernel and in additional projects. We will have a closer look at this aspect a little later.
As mentioned before, SONiC is built on the Debian Linux distribution that is renowned for its robustness. While it might not include all of the latest bells and whistles available in the Linux kernel and its ecosystem, as a base for a reliable network operating system, we will prefer the former over the latter.
Containers
We have heard that SONiC makes use of containers to implement a modular architecture. This approach gives us several benefits. First of all, containers are isolated from each other, so one misbehaving container cannot affect other containers. Still, containers can communicate with each other in a controlled fashion. Also, each container brings its own packages on which it depends and its own environment. This helps the container to always behave the same no matter on which system we run it.
If we compare a container to a virtual machine as another means of isolation, we will realize that containers are much more lightweight. They share the kernel with the host system, so they don’t have to run individual copies of the kernel in each of them. This fact, together with a much easier way of communication between them, makes them much more suitable for our purpose than VMs.
Finally, it is very easy to add new containers to SONiC, thereby expanding its functionality. For example, we could add a container implementing a DHCP server, which is not available in standard SONiC. Enterprise SONiC will even allow us to control the resource usage of such containers, so we don’t have to sacrifice stability for extensibility.
SONiC uses Docker to implement its containers. Docker is probably the most popular implementation of containers and thereby has grown to a very robust and flexible product. As we will see in the next lesson, almost every networking function, as well as several base functions, will run in their own container.
Linux networking
As we mentioned before, Linux already comes with a lot of networking functionality that SONiC can leverage. This includes both features built into the kernel as well as external projects.
It starts with the IPv4 and IPv6 protocol stack that is built into the kernel. This not only facilitates interface addressing, but also basic protocols like ARP, Neighbor Discovery, and router advertisements. Also, the kernel supports virtual routing and forwarding (VRF) functions that help us establish separate routing tables in one system. This is a very important feature to support overlay networks.
What additional Linux packages are used by SONiC? The most important one is probably FRR, or Free Range Routing, that provides an implementation of all the routing protocols supported by SONiC. Also, a very important one is teamd, a package that controls link aggregation. Then we will find an instance of ISC DHCP Relay, which can forward DHCP requests across a layer 3 network to a central DHCP server, and several other packages.
The use of all of these packages helps to avoid new implementations of mature protocols in SONiC, leveraging the reliability and experience of the existing implementations, and as a consequence, adding to the stability of SONiC, since little new code had to be written to support these protocols. Still, we may see a few modifications from the upstream versions of these packages, either to enhance the functionality in certain places or to further improve the quality of the code. As we all know, no software is without bugs.
Redis databases
Another important component in SONiC is Redis databases. Redis databases are fast in-memory data stores that can serve both as a repository and a cache. They also provide some degree of persistence. They are not like relational databases, but implement a key-value paradigm where you get or set the value of an object with a given key. They also provide different data types. If you want to learn more about Redis databases, follow the link given on the slide.
In SONiC, there are multiple instances of Redis databases that constitute a single source of truth of the switch state. This means that all switch configuration, any routing or forwarding tables or similar, counters, the states of ports, modules, fans, and so on are all stored in these databases. They are running in a separate database container and are accessed by most other containers. These either act as publishers, that is, they write information about new states or events to a database, or as subscribers, which consume such information. Some processes act both as publishers and subscribers.
SAI – Switch Abstraction Interface
One of the most distinctive concepts of SONiC is the abstraction of the intrinsics of a particular switching ASIC through a uniform programming interface, which makes SONiC agnostic of the underlying ASIC and therefore eases the porting of SONiC to new ASICs. This abstraction is achieved with the help of SAI, the Switch Abstraction Interface.
It is a separate open source project governed by the OCP, the Open Compute Project. It is a vendor-independent API that allows you to control any switching ASIC for which there is an implementation of SAI. This avoids the need to obtain licensing, etc., for the ASIC-specific SDK that would be the direct interface to program the ASIC. With SONiC relying on SAI to control the switching ASIC, not only is porting to new ASICs simplified, which supports the spread of SONiC, but also no ASIC-dependent code is required in SONiC.
One important thing to note is that SAI really only provides an interface to the switching ASIC. It does not include support for other hardware elements that can be found in typical switching platforms like LEDs, fans, thermal sensors, power supplies, and inserted modules. The access to these components is a platform-specific implementation that is in fact part of SONiC. More information about SAI can be found on the website of the OCP by following the link on the slide.
