The previous section described at a high level how the config_db.json file is loaded into the Redis CONFIG_DB database in the Database container. Next we look at the topic in slightly more detail. First, we examine how physical port information, such as the port's default speed and lane configuration, is processed during the initial boot before it is programmed into the switch ASIC.
Step 1: Creating a Config_db.json and Updating CONFIG_DB by Sonic-cogent
Figure
4-2 illustrates how platform-specific port information becomes the PORT and
BREAKOUT_CFG entries stored in the Redis CONFIG_DB database. During the image
initialization process, sonic-cfggen uses the platform-specific port_config.ini
file (1) together with other platform configuration files and templates to
generate the port-related entries in the config_db.json file (2). The
port_config.ini file defines the logical, expected physical characteristics of
the switch ports, including the front-panel alias names, lane mappings, index
values, subport values, and default port speeds. After the config_db.json file
has been generated, its contents are loaded into the Redis CONFIG_DB database
during the SONiC boot process (3).
Figure
4-2 also shows the DEVICE_METADATA table, which contains platform-specific
information such as the base MAC address, switch_type, buffer_model, and hwsku
(hardware stock keeping unit identifier). During the initial boot process, the
portmgrd daemon uses the selected HwSKU together with platform-specific
configuration information to validate the port configuration before publishing
it to the APPL_DB database. The validation verifies that parameters such as the
configured port speed, lane mapping, and breakout mode are supported by the
selected hardware platform.
Figure 4-2: Creating/Updating
a CONFIG_DB based on the Config_db.json.
A
SONiC distribution may support several hardware platforms. In our example, we
are using the SONiC Virtual Switch image. To locate the appropriate
port_config.ini file, we first need to determine the platform and HwSKU used by
the virtual switch. This information is displayed by the show platform
summary command, shown in Example 4-3. The output
identifies the platform as x86_64-kvm_x86_64-r0 and the HwSKU as Force10-S6000.
root@leaf-1:/# show platform
summary
/bin/sh: 1: sudo: not found
Platform:
x86_64-kvm_x86_64-r0
HwSKU:
Force10-S6000
ASIC: vs
ASIC Count: 1
Serial Number: N/A
Model Number: N/A
Hardware Revision: N/A
Switch Type: switch
Example 4-3:
Platform Summary.
Next, we verify that the corresponding port_config.ini
file exists by using the Linux command:
ls -l /usr/share/sonic/device/x86_64-kvm_x86_64-r0/Force10-S6000
The output in Example
4-4 lists the platform-specific files in specified directory. Besides port_config.ini,
the directory contains numerous other files used to describe platform-specific
settings such as buffer management, and QoS policies.
root@leaf-1:/# ls -l
/usr/share/sonic/device/x86_64-kvm_x86_64-r0/Force10-S6000
total 92
drwxr-xr-x 2 root root 4096 Apr 24 14:34 BALANCED
drwxr-xr-x 2 root root 4096 Apr 24 14:34 RDMA-CENTRIC
drwxr-xr-x 2 root root 4096 Apr 24 14:34 TCP-CENTRIC
-rw-r--r-- 1 root root 221 Feb 20
2017 buffer_ports_t0.j2
-rw-r--r-- 1 root root 221 Feb 20
2017 buffer_ports_t1.j2
-rw-r--r-- 1 root root 66 Feb 20
2017 buffers.json.j2
-rw-r--r-- 1 root root 1069 Feb 20
2017 buffers_defaults_t0.j2
-rw-r--r-- 1 root root 1070 Feb 20
2017 buffers_defaults_t1.j2
-rw-r--r-- 1 root root 174 Feb 20
2017 fabriclanemap.ini
-rw-r--r-- 1 root root 799 Feb 20
2017 lanemap.ini
-rw-r--r-- 1 root root 223 Feb 20
2017 pai.profile
-rw-r--r-- 1 root root 812 Feb 20
2017 pg_profile_lookup.ini
-rw-r--r--
1 root root 3953 Feb 20 2017 port_config.ini
-rw-r--r-- 1 root root 775 Feb 20
2017 qos.json.j2
-rw-r--r-- 1 root root 302 Feb 20
2017 sai.profile
-rw-r--r-- 1 root root 728 Feb 20
2017 sai.profile.j2
-rw-r--r-- 1 root root 302 Feb 20
2017 sai_mlnx.profile
-rw-r--r-- 1 root root 10607 Feb
20 2017 th-s6100-64x40G-t0.config.bcm
-rw-r--r-- 1 root root 10607 Feb
20 2017 th-s6100-64x40G-t1.config.bcm
Example 4-4:
Files in Force10-S6100 directory.
We
can examine the contents of the port_config.ini file by using the command:
cat
/usr/share/sonic/device/x86_64-kvm_x86_64-r0/Force10-S6000/port_config.ini
Example
4-5 shows two interfaces, Ethernet0 and Ethernet4, with their lane mappings,
front-panel alias names, index values, and default speeds. Although Ethernet4
appears first in this excerpt, Ethernet0 has index value 0, while Ethernet4 has
index value 1.
Note: SONiC derives logical Ethernet interface
numbering from the physical lane mapping. Since Ethernet0 occupies four
physical lanes (25-28), the next interface begins at lane 29 and is therefore
named Ethernet4.
root@leaf-1:/# cat
/usr/share/sonic/device/x86_64-kvm_x86_64-r0/Force10-S6000/port_config.ini
# name lanes alias index speed
Ethernet4 29,30,31,32 fortyGigE0/4 1 40000
Ethernet0 25,26,27,28 fortyGigE0/0 0 40000
Example 4-5:
The Content of the Port_config.ini File.
The resulting
configuration generated by sonic-cfggen can be viewed by using the command:
cat /etc/sonic/config_db.json
file.
Example 4-6 shows the
DEVICE_METADATA table together with the PORT entry for Ethernet0. The values in
the PORT table are derived from the platform-specific configuration, while the
DEVICE_METADATA table contains information describing the hardware platform.
root@leaf-1:/# cat
/etc/sonic/config_db.json
{
"DEVICE_METADATA": {
"localhost": {
"mac": "6e:fc:2e:c2:81:22",
"switch_type":
"switch",
"buffer_model":
"traditional",
"hwsku":
"Force10-S6000"
}
"PORT": {
"Ethernet0": {
"alias":
"fortyGigE0/0",
"lanes":
"25,26,27,28",
"speed": "40000",
"index": "0",
"subport": "0"
},
Example 4-6:
The Content of the Config_db.json File.
Example
4-7 shows the corresponding entries stored in the Redis CONFIG_DB database by
using the command:
sonic-db-dump -n CONFIG_DB --pretty.
The
database is organized into tables, where each table represents a particular
configuration category. Each table contains one or more keys, and every key
consists of a set of field/value pairs. In this example, the PORT table
contains the key PORT|Ethernet0, while the BREAKOUT_CFG and DEVICE_METADATA
tables contain the keys BREAKOUT_CFG|Ethernet0 and DEVICE_METADATA|localhost,
respectively.
root@leaf-1:/# sonic-db-dump
-n CONFIG_DB --pretty
{
"BREAKOUT_CFG|Ethernet0": {
"expireat": 1784018980.3639462,
"ttl": -0.001,
"type": "hash",
"value": {
"brkout_mode": "1x40G"
}
},
"PORT|Ethernet0": {
"expireat": 1784019105.4230292,
"ttl": -0.001,
"type": "hash",
"value": {
"alias":
"fortyGigE0/0",
"index": "0",
"lanes":
"25,26,27,28",
"speed": "40000",
"subport": "0"
}
},
"DEVICE_METADATA|localhost": {
"expireat": 1784019105.448699,
"ttl": -0.001,
"type": "hash",
"value": {
"buffer_model":
"traditional",
"hwsku":
"Force10-S6000",
"mac": "6e:fc:2e:c2:81:22",
"switch_type":
"switch"
}
},
Example 4-7:
CONFIG_DB – Ethernet0 Field/Value Pairs#1.
The previous example
displays the complete contents of the CONFIG_DB database. If you want to
display only the field/value pairs associated with Ethernet0 in the PORT table,
you can use the Redis command:
redis-cli -n 4 HGETALL
"PORT|Ethernet0".
root@leaf-1:/# redis-cli
-n 4 HGETALL "PORT|Ethernet0"
1) "alias"
2) "fortyGigE0/0"
3) "index"
4) "0"
5) "lanes"
6) "25,26,27,28"
7) "speed"
8) "400000"
9) "subport"
10)
"0"
11)
"admin_status"
12)
"up"
Example 4-8:
CONFIG_DB – Ethernet0 Field/Value Pairs#2.
Note:
The admin_status field is not defined in the port_config.ini file because that
file describes only the platform's physical port characteristics. The
administrative state is applied later as part of the interface configuration.
If config_db.json does not explicitly configure the administrative state, SONiC
keeps the interface administratively down by default. Consequently, the
contents of the PORT entry in CONFIG_DB may change after the initial
configuration has been loaded.
Step 2: Updating APPL_DB by Portmgrd
The portmgrd
daemon running in the SWSS container is responsible for translating the port
configuration stored in CONFIG_DB into application-level objects stored in
APPL_DB. Figure 4-3 depicts this process. When the PORT table in CONFIG_DB is
updated, Redis notifies the SWSS database framework that the corresponding key
has changed (4). Rather than periodically polling the database for changes,
portmgrd reacts to these notifications, allowing the updated port configuration
to be processed immediately after it is written to CONFIG_DB. The portmgrd
daemon then retrieves the complete set of field/value pairs associated with the
modified port (5). Then it validates the configuration using the selected HwSKU
together with platform-specific configuration information, and resolves any
configuration dependencies (6). During this process, portmgrd also adds default
attributes required by the SONiC application layer, such as the interface MTU
and administrative state. After the validation is completed successfully,
portmgrd publishes the resulting port object to the PORT_TABLE in APPL_DB (7).
Figure 4-3: Information
Flow from CONFIG_DB to APPL_DB.
Example 4-9 shows the PORT_TABLE:Ethernet0
entry printed by using the command:
sonic-db-dump -n APPL_DB --pretty.
Similar to CONFIG_DB,
the APPL_DB database is organized into tables, where each key contains a
collection of field/value pairs describing the corresponding object. Compared
to the PORT entry in CONFIG_DB, the PORT_TABLE entry contains additional
attributes such as admin_status, oper_status, mtu, and flap_count, which are
required by other SONiC components during the hardware programming process.
root@leaf-1:/# sonic-db-dump
-n APPL_DB –pretty
<snipped for brevity>
"PORT_TABLE:Ethernet0":
{
"expireat": 1784020527.8656764,
"ttl": -0.001,
"type": "hash",
"value": {
"admin_status":
"down",
"alias":
"fortyGigE0/0",
"flap_count": "0",
"index": "0",
"lanes":
"25,26,27,28",
"mtu": "9100",
"oper_status":
"down",
"speed": "40000",
"subport": "0"
}
},
<snipped for brevity>
Example 4-9:
APPL_DB – Ethernet0 Field/Value Pairs#1.
To display only the
field/value pairs associated with Ethernet0, use the Redis command:
redis-cli -n 0 HGETALL
"PORT_TABLE:Ethernet0".
root@leaf-1:/# redis-cli -n 0
HGETALL "PORT_TABLE:Ethernet0"
1) "alias"
2) "fortyGigE0/0"
3) "index"
4) "0"
5) "lanes"
6) "25,26,27,28"
7) "speed"
8) "40000"
9) "subport"
10) "0"
11) "oper_status"
12) "down"
13) "flap_count"
14) "0"
15) "mtu"
16) "9100"
17) "admin_status"
18) "up"
Example 4-10:
APPL_DB – Ethernet0 Field/Value Pairs#2.
Note: As mentioned before, the PORT_TABLE
entry in APPL_DB is not a direct copy of the PORT entry in CONFIG_DB. Besides
the configuration parameters retrieved from CONFIG_DB, portmgrd adds default
values and application-specific attributes during the validation process. Some
fields, such as oper_status, are updated later as the switch learns the actual
operational state of the interface. This illustrates an important architectural
principle of SONiC: CONFIG_DB stores the desired configuration, whereas
APPL_DB stores the application's runtime view of the configured object.
Step 3: Discovering ASIC Port Information
At this point both
CONFIG_DB and APPL_DB have been updated, and the port configuration is ready to
be translated into SAI objects. After PortMgrd updates the PORT_TABLE in
APPL_DB, Redis sends a notification to Orchagent in the SWSS container (8).
Orchagent dispatches the notification to the PortOrch orchestrator (9), which
is responsible for keeping the port information synchronized with the ASIC.
PortOrch then retrieves the updated keys from APPL_DB (10).
Figure 4-4: Updating
ASIC_DB by PortOrch.
During the
initialization process, the Syncd daemon in the Syncd container queries
physical port information from the ASIC through the Vendor SDK implementation
(11). The Vendor SDK retrieves the requested port attributes from the ASIC and
returns them to Syncd (12). Figure 4-5 shows how the lane mapping is stored in
the SAI_PORT_ATTR_HW_LANE_LIST attribute of the port object
oid:0x1000000000002. After receiving the response, Syncd updates ASIC_DB (13),
which generates a Redis notification to Orchagent in the SWSS container (14).
Orchagent dispatches the notification to the PortOrch orchestrator (15), which
retrieves the updated entries from the ASIC_STATE table in ASIC_DB (16).
PortOrch has already
learned the lane mapping of interface Ethernet0 from APPL_DB. It compares this
information with the lane mapping reported by the ASIC (17). This validation
step ensures that the lane mapping programmed in the switch matches the lane mapping
discovered from the hardware.
Figure 4-5: Information
Flow from CONFIG_DB to APPL_DB.
Step 4: Programming the ASIC
As the final step,
PortOrch updates the ASIC_DB(18). The update generates a Redis notification to
the Syncd daemon (19). Syncd retrieves the updated information from ASIC_DB
(20), translates it into Vendor SDK calls (21), and programs the port into the
ASIC (22).
ASIC_DB: Resolving OID-to-PORT mapping
The ASIC uses object
identifiers (OIDs) to identify hardware objects. For example, SONiC identifies
the first physical port as Ethernet0, while the ASIC refers to the same port by
its OID. To inspect the port information stored in ASIC_DB, we must first determine
which OID corresponds to Ethernet0.
Example 4-11 lists all
keys in the ASIC_STATE table related to SAI_OBJECT_TYPE_PORT and
SAI_OBJECT_TYPE_PORT_SERDES. Our goal is to identify the OID associated with
Ethernet0.
root@leaf-1:/# redis-cli -n 1
KEYS "ASIC_STATE:SAI_OBJECT_TYPE_PORT*"
1)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000371"
2)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000569"
3)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000008f"
4)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x5700000000024b"
5)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000004c1"
6)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000092"
7)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000009f"
8)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000008b"
9)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000008c"
10)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000000d1"
11)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000004eb"
12)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x5700000000053f"
13)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x5700000000039b"
14)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x5700000000031d"
15)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000001f7"
16)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x5700000000029f"
17)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000003c5"
18)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x10000000000a1"
19)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000008e"
20)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x10000000000a7"
21)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000125"
22)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000091"
23)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x10000000000a2"
24)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000096"
25)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x10000000000a0"
26)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000099"
27)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000098"
28)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000275"
29)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000009e"
30)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000003ef"
31)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000347"
32)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000009d"
33)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000002f3"
34)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000003"
35)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000497"
36)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x10000000000a5"
37)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000090"
38)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000419"
39)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000094"
40)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000008d"
41)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000082"
42)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000000fb"
43)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x10000000000a6"
44)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000009a"
45)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000001a3"
46)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000081"
47)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x5700000000014f"
48)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000093"
49)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x10000000000a4"
50)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000001cd"
51)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000009c"
52)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000179"
53)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000515"
54)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000001"
55)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000002"
56)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000443"
57)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x10000000000a3"
58)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x5700000000046d"
59)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000095"
60)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000221"
61)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x57000000000593"
62)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT_SERDES:oid:0x570000000002c9"
63)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000008a"
64)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x100000000009b"
65)
"ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000097"
Example 4-11:
ASIC_DB – ASIC_STATE:SAI_OBJECT_TYPE_PORT.
There are several ways
to resolve the OID-to-port mapping. One of the simplest methods is shown in
Example 4-12 by using the command:
redis-cli -n 2 HGETALL
COUNTERS_PORT_NAME_MAP.
This command retrieves
the contents of the COUNTERS_PORT_NAME_MAP table in COUNTERS_DB, where each
entry maps a SONiC port name to its corresponding OID.
root@leaf-1:/# redis-cli -n 2
HGETALL COUNTERS_PORT_NAME_MAP
1) "Ethernet0"
2)
"oid:0x1000000000002"
3) "Ethernet4"
4)
"oid:0x1000000000003"
Example 4-12:
COUNTERS_DB – Port:SAI_OBJECT_TYPE_PORT mapping.
After identifying the
OID, we can inspect the corresponding port object stored in ASIC_DB by using
the following command:
redis-cli -n 1 HGETALL ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000002"
The exact contents of a
SAI_OBJECT_TYPE_PORT object depend on the SAI implementation and the underlying
hardware platform. Example 4-13 shows a typical set of attributes associated
with the Ethernet0 port object.
root@leaf-1:/# redis-cli -n 1
HGETALL ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000002"
1) "NULL"
2) "NULL"
3)
"SAI_PORT_ATTR_HW_LANE_LIST"
4)
"4:25,26,27,28"
5)
"SAI_PORT_ATTR_SPEED"
6) "40000"
7)
"SAI_PORT_ATTR_HOST_TX_SIGNAL_ENABLE"
8) "false"
9)
"SAI_PORT_ATTR_ADMIN_STATE"
10) "false"
11) "SAI_PORT_ATTR_MTU"
12) "9100"
Example 4-13:
ASIC_DB – Updated SAI_OBJECT_TYPE_PORT Field/Values.
Summary
The previous examples
focused on port initialization to illustrate how SONiC programs hardware
through the Redis databases, Orchagent, and Syncd. Although only the basic port
configuration was used as an example, the same programming model is used throughout
SONiC. Additional port-related settings, such as breakout configuration, buffer
allocation, queue and priority settings, flow control, and many other port
attributes, follow the same sequence. The configuration is first written into
CONFIG_DB, processed by the corresponding manager daemon into APPL_DB,
translated into SAI objects by Orchagent, and finally programmed into the ASIC
by Syncd through the Vendor SDK implementation.
PortOrch is only one of
several orchestrators running under the Orchagent process. Each orchestrator is
responsible for translating a specific type of configuration into SAI objects.
For example, IntfOrch programs Layer 3 interfaces, VlanOrch manages VLANs,
RouteOrch programs routing entries, NeighborOrch resolves neighbor information,
and BufferOrch manages buffer-related resources. Together, these orchestrators
ensure that the configuration stored in Redis databases is consistently
translated into the hardware-specific objects required by the ASIC.
Understanding this
programming pipeline is essential for understanding how SONiC operates.
Regardless of whether the configuration relates to ports, VLANs, routing, QoS,
or another feature, the same overall workflow is followed: the configuration is
stored in Redis, processed by the appropriate manager daemon and orchestrator,
translated into SAI objects, and finally programmed into the ASIC.
Looking Ahead
This chapter concludes
the discussion of the SONiC boot and initialization process. Starting from the
Linux boot sequence in Chapter 3, we have followed the complete path of the
initial switch configuration from the config_db.json file into CONFIG_DB, through
the SWSS container, and finally into the ASIC. Understanding this process
provides a solid foundation for the remaining chapters, where the switch is
configured to perform actual networking functions.
The next part of the
book shifts from the startup process to building a complete Clos fabric by
using SONiC. We begin by configuring the inter-switch links, continue by
enabling the IP underlay, and finally build a BGP EVPN overlay with VXLAN data
plane. Rather than focusing only on the SONiC CLI configuration, each phase
also explains what happens internally. You will see how the configuration is
written into the Redis databases, which manager daemons and orchestrators
process the changes, how the different containers cooperate, and how the
resulting configuration is translated into SAI objects before being programmed
into the ASIC.
By examining both the
configuration steps and the internal processing pipeline, you will gain a
deeper understanding of how SONiC implements modern data center networking.
This approach not only explains how to configure SONiC, but also why the
configuration works the way it does.
