SONIC Part III: SONiC Introduction

SONiC is a vendor-neutral, Linux-based network operating system (NOS) that uses a database-driven architecture. Its software components run in multiple containers and exchange information through Redis. In SONiC, several named databases are defined for different functions, and these databases are mapped to Redis logical database IDs. Through this design, configuration data, application state, operational state, and ASIC-related state move between software layers by means of specialized processes.

Different hardware vendors may add their own platform integrations, transceiver support, monitoring utilities, or management workflows. However, the core SONiC architecture remains the same. This is one of the main reasons why SONiC knowledge, troubleshooting methods, and automation practices are transferable across different hardware platforms.

Vendor neutrality does not mean that every SONiC-based implementation behaves exactly the same in every operational detail. It means that different implementations follow the same architectural model. To organize information clearly, SONiC defines several named databases, each of which is mapped to a Redis logical database ID:

·       CONFIG_DB (Redis DB 4): Stores the user’s intended configuration.

·       APPL_DB (Redis DB 0): Stores application-level objects that are ready for processing by lower software layers.

·       STATE_DB (Redis DB 6): Stores operational state information about system components.

·       ASIC_DB (Redis DB 1): Stores objects in a form used by the SONiC and SAI pipeline for hardware programming.

Figure 1-01 shows the relationship between Redis logical databases and SONiC databases from a routing-oriented point of view. A standard Redis instance commonly provides sixteen logical databases by default, and SONiC uses a defined subset of them for its core functions.

As shown in the routing example in Figure 1-01, APPL_DB contains a native Redis Set called ROUTE_TABLE_KEY_SET. This set tracks route-related keys, but it does not store route attributes such as next-hop or metric values. The actual routes are stored as separate Redis keys that follow SONiC’s table-and-key naming convention, where the table name and the object identifier are joined with a colon. Examples include ROUTE_TABLE:192.168.1.1/32 for a host route and ROUTE_TABLE:10.1.1.0/30 for a network route. Route attributes are stored as field-value pairs in a Redis Hash, which SONiC uses to represent structured objects in its databases.

The following chapters build on this foundation. First, we examine what happens when an interface changes from down to up and receives an IP address configuration. Next, we trace the internal processes that begin when a BGP session is established and the system starts handling BGP UPDATE messages. By moving from interface bring-up to control-plane route learning, you will see how configuration data and protocol state pass through the software layers until the resulting forwarding information is programmed into the switch hardware.

Figure 1-01 also includes config_db.json to indicate that persistent configuration is stored outside Redis and is loaded into CONFIG_DB during startup, while the detailed workflow is covered in later sections.

Figure 1-01: Relationship Between Redis Logical Databases and SONiC Databases.