SONiC: Populating CONFIG_DB

Introduction

Before a switch can forward data traffic, its ASIC must first be programmed with the device's port configuration. This includes information such as the number of front-panel ports, their supported speeds, the number of lanes assigned to each port, the speed of each lane, and the administrative and operational state of every port.

SONiC relies heavily on a Redis-based database model. During startup, the configuration stored in config_db.json is loaded into CONFIG_DB. The *mgrd daemons running inside the SWSS container then receive the changes relevant to them through Redis Pub/Sub notifications. After a daemon has processed its part of the configuration, it publishes the corresponding application-level state to APPL_DB.

The orchagent process in the SWSS container monitors changes in APPL_DB, translates the application-level state into hardware objects suitable for ASIC programming, and publishes the resulting hardware objects to ASIC_DB. The actual ASIC programming takes place in the next stage: the syncd container monitors ASIC_DB changes and passes them through the SAI interface to the vendor-specific SDK, which interacts with the ASIC driver stack to program the physical switch ASIC.

This chapter focuses on port programming because it clearly illustrates the complete programming pipeline. Other configuration objects follow the same general processing model and are therefore covered more briefly.

Populating CONFIG_DB

As discussed in Chapter 3, Linux systemd starts SONiC services according to their unit files. Several services may belong to the same startup transaction. However, service execution order is determined by the dependency and ordering directives defined in their unit files. Figure 4-1 presents a simplified view of the startup sequence that initializes the database container and populates CONFIG_DB with the contents of config_db.json. The config_db.json file contains the switch's persistent configuration, including port definitions, interface settings, VLANs, routing configuration, and other management-plane configuration. Runtime configuration changes may later be written back from CONFIG_DB to config_db.json so that they persist across reboots.

Linux systemd first starts docker.service, database.service, and config-setup.service (1a–1c) according to the sequence described in the unit files section. After the required initialization steps are complete, docker.service starts the Docker Engine (2). Although database.service is started simultaneously, it waits until the Docker Engine becomes fully operational (3). It then invokes database.sh to start the database container (4). At the same time, config-setup.service performs tasks related to device configuration. It verifies whether config_db.json exists and, if not, creates a new one. It may also migrate an older configuration into the file (5). Database.service must wait until the database container is up and running and config_db.json exists (6). Finally, it invokes sonic-cfggen to parse config_db.json (7) and write the parsed configuration to CONFIG_DB (8).

Note: The SONiC service initialization process shown in Figure 4-1 is simplified and may vary between SONiC distributions and software releases. In this context, config_db.json refers to the persistent configuration file stored on disk, whereas CONFIG_DB refers to the in-memory Redis database that is populated from config_db.json during system startup.

Figure 4-1: High-Level Overview of the SONiC Container Startup Process.

Verification

Example 4-1 verifies that the database initialization script, /usr/bin/database.sh, contains the command used to load the persistent config_db.json file into CONFIG_DB during system startup. Use the following command to display the relevant section of the script:

 

admin@sonic:~$ grep -A2 -n "config_db.json dump file" /usr/bin/database.sh

Example 4-1: Config_db.json.

The output should include a section similar to that shown in Example 4-2.

 

$SONIC_CFGGEN -j /etc/sonic/config_db$DEV.json --write-to-db

Example 4-2: Docker - docker stats container resource usage.

The sonic-cfggen command reads and parses the config_db.json file and writes the resulting configuration into CONFIG_DB. The command-line options have the following meaning:

·       -j specifies the JSON configuration file to parse.

·       --write-to-db writes the parsed configuration directly into CONFIG_DB instead of printing it to the terminal.