SONiC Deep Dive: Interface State Change Pipeline

Enable Interface Ethernet0

After creating VLAN 10, the next step is to enable interface Ethernet0. The baseline configuration for Ethernet0 already exists in the PORT table of CONFIG_DB. This configuration is populated during the SONiC switch startup process using the platform configuration and configuration files, including config_db.json. When the switch boots, the configuration from config_db.json is loaded into CONFIG_DB, which is implemented as a Redis database.

 

GONFIG_DB and APPL_DB

The SONiC command config interface startup Ethernet0 does not create the complete PORT|Ethernet0 entry to the CONFIG_DB. Instead, it changes the administrative state of the existing port configuration. In this example, the admin_status field of PORT|Ethernet0 is changed to up (1).

 

After admin_status is changed, Redis generates a notification for applications subscribed to the PORT table in CONFIG_DB (2). The Redis notification indicates that the configuration entry has changed. It identifies the affected key and the operation that occurred rather than containing the complete PORT|Ethernet0 configuration. portmgrd, running in the SWSS container, is one of the SONiC components involved in processing port configuration. portmgrd uses the notification to identify the changed key and retrieves the current field/value data from CONFIG_DB. It then processes the configuration and prepares the port information for the next stage of the SONiC configuration pipeline (3).

portmgrd writes the resulting port information to APPL_DB through the Redis database interface (4). Redis stores the data in APPL_DB and generates a notification for APPL_DB subscribers (5). Components such as orchagent can then receive the notification and process the updated port information. 

Figure 5-6: Updating Redis Databases: Port State Change - from CONFIG_DB to APPL_DB.

 

Verifying CONFIG_DB and APPL_DB

 

Examples 5-5 and 5-6 show the commands used to examine the CONFIG_DB and APPL_DB entries related to Ethernet0. The table name in CONFIG_DB is PORT, while the corresponding table in APPL_DB is PORT_TABLE. The key separator is also different: CONFIG_DB uses a pipe (|) between the table name and the object name, while APPL_DB uses a colon (:). Therefore, the Ethernet0 key is PORT|Ethernet0 in CONFIG_DB and PORT_TABLE: Ethernet0 in APPL_DB.

 

Most of the fields are self-explanatory, while some require additional explanation.

 

·       adv_speeds specifies the Ethernet speeds that the port can advertise during Ethernet auto-negotiation. In this example, autoneg is off, so this setting does not affect the current link negotiation.

·       alias provides the platform-specific front-panel name associated with the SONiC interface name. In this example, SONiC interface Ethernet0 has the front-panel alias Eth1/1.

·       fec stands for Forward Error Correction. FEC adds redundant information to transmitted data so that the receiver can detect and correct certain bit errors. The value none means that FEC is not configured for Ethernet0.

·       index identifies the port within the platform's port configuration. In this example, Ethernet0 has index 1. Port indexes are assigned according to the platform's port configuration and should not be interpreted simply as the number in the SONiC interface name.

·       lanes identifies the SerDes lanes assigned to the port. Ethernet0 uses lane 49 in this example. The exact lane numbering is platform-specific.

·       link_training refers to a PHY-level process in which the two ends of a high-speed Ethernet link adjust transmitter and receiver parameters to optimize the signal. A value of off means that link training is not enabled for Ethernet0.

·       unreliable_los controls how an indication of an unreliable Loss of Signal (LOS) condition is handled. The value auto allows the platform implementation to determine the appropriate behaviour rather than explicitly forcing the setting on or off.

·       The speed field is 25000, meaning that Ethernet0 is configured for 25 Gb/s operation. The mtu is 9100.

 

An important difference can be seen when comparing the CONFIG_DB and APPL_DB entries. The CONFIG_DB entry primarily contains the configuration of Ethernet0, while the APPL_DB entry also contains operational information reported by the system. For example, oper_status shows the current operational state of the port, while admin_status shows its configured administrative state. Similarly, oper_speed shows the current operational speed.

In this example, both admin_status and oper_status are up, indicating that Ethernet0 is administratively enabled and currently operational. The reason field reports OPER_UP, indicating the reason associated with the current operational state. Other fields, such as last_change and oper_status_change_uptime, provide information about changes to the port's operational state.

 

 

admin@sonic:~$ sonic-db-dump -n CONFIG_DB --pretty -k 'PORT|Ethernet0'

{

  "PORT|Ethernet0": {

    "expireat": 1786165989.3673553,

    "ttl": -0.001,

    "type": "hash",

    "value": {

      "admin_status": "up",

      "adv_speeds": "all",

      "alias": "Eth1/1",

      "autoneg": "off",

      "fec": "none",

      "index": "1",

      "lanes": "49",

      "link_training": "off",

      "mtu": "9100",

      "speed": "25000",

      "unreliable_los": "auto"

    }

  }

}

Example 5-5: CONFIG_DB: Port Table KKey PORT|Ethernet0.

 

admin@sonic:~$ sonic-db-dump -n APPL_DB --pretty -k 'PORT_TABLE:Ethernet0'

{

  "PORT_TABLE:Ethernet0": {

    "expireat": 1786166014.8652368,

    "ttl": -0.001,

    "type": "hash",

    "value": {

      "admin_status": "up",

      "adv_speeds": "all",

      "alias": "Eth1/1",

      "autoneg": "off",

      "description": "",

      "fec": "none",

      "index": "1",

      "lanes": "49",

      "last_change": "1786165960",

      "link_training": "off",

      "mtu": "9100",

      "oper_speed": "25000",

      "oper_status": "up",

      "oper_status_change_uptime": "1909",

      "port_load_interval": "10",

      "reason": "OPER_UP",

      "speed": "25000",

      "unreliable_los": "auto"

    }

  }

}

Example 5-6: : CONFIG_DB: Port Table Key PORT_TABLE:Ethernet0.

 

Processing Ethernet0 from APPL_DB to ASIC_DB

 

Figure 5-7 illustrates the next stage of the Ethernet0 configuration process, where the port configuration stored in APPL_DB is processed by orchagent and represented as SAI objects in ASIC_DB. Unlike the creation of VLAN 10 described earlier, this operation does not create a new SAI port object. The SAI port (SAI_OBJECT_TYPE_PORT) and host-interface objects (SAI_OBJECT_TYPE_HOSTIF) for Ethernet0 already exist in ASIC_DB. The configuration change results in an update to the relevant attributes of the existing SAI port object.

 

After portmgrd has written the Ethernet0 configuration to the PORT_TABLE in APPL_DB, Redis generates a notification for applications subscribed to the table. The orchagent, running in the SWSS container, is one of the subscribers and receives the notification (phase 6).

 

The notification indicates that the PORT_TABLE:Ethernet0 entry has changed. As with the CONFIG_DB notification described earlier, the notification should not be considered the complete port configuration. orchagent uses the notification to identify the affected APPL_DB key and retrieves the current field/value data from APPL_DB (phase 7).

 

orchagent then passes the port configuration to PortOrch, the port orchestration component responsible for processing port configuration (phase 8). PortOrch processes the requested port configuration, validates the relevant values, determines the required SAI operation, and applies the operation to the corresponding port object. In this example, the change is the administrative state of Ethernet0 (admin_status = up). Because the corresponding SAI port object already exists, PortOrch does not need to create a new SAI_OBJECT_TYPE_PORT object. Instead, it prepares an update to the appropriate SAI port attribute. The administrative state is represented by the SAI attribute SAI_PORT_ATTR_ADMIN_STATE.

 

PortOrch uses the SAI interface through libsairedis to perform the requested operation (phase 9). libsairedis provides the interface between the SAI API calls made by SONiC components such as orchagent and the Redis-based representation used for ASIC_DB. It serializes the SAI operation into the format required for storage in Redis (phase 10).

 

The serialized SAI operation is then written to Redis by the SAI Redis interface (phase 11). Redis updates the corresponding entry in ASIC_DB (12).

 

The ASIC_DB contains different SAI objects representing different aspects of Ethernet0. The SAI_OBJECT_TYPE_PORT object represents the Ethernet port used by the SAI/ASIC programming path. In this example, its OID is oid:0x1000000000002, and its SAI_PORT_ATTR_ADMIN_STATE attribute is true, indicating that the administrative state of the SAI port is enabled.

 

The ASIC_DB also contains an existing SAI_OBJECT_TYPE_HOSTIF object representing the host interface associated with the Linux network device Ethernet0. Its SAI_HOSTIF_ATTR_NAME attribute identifies the host interface as Ethernet0, while its SAI_HOSTIF_ATTR_OBJ_ID attribute references the SAI port OID oid:0x1000000000002. This establishes the relationship between the host interface and the SAI port.

 

This relationship is important because Ethernet0 has both an ASIC-facing representation and a Linux-facing representation. The SAI_OBJECT_TYPE_PORT object participates in the SAI/ASIC programming path, while the SAI_OBJECT_TYPE_HOSTIF object represents the corresponding Linux network device. Linux kernel state changes associated with the interface are reported through netlink and can subsequently be processed by portsyncd and published to STATE_DB. The netlink and STATE_DB processing is described in a later section.

Figure 5-7: Updating Redis Databases: Port State Change - from APPL_DB to ASIC_DB.

 

Processing Ethernet0 from ASIC_DB to the Hardware ASIC

Figure 5-8 depicts the next stage of the Ethernet0 configuration process, where the SAI operation stored in ASIC_DB is processed by syncd and ultimately applied to the hardware ASIC. After libsairedis writes the serialized SAI operation to Redis, Redis updates ASIC_DB and generates a notification for applications subscribed to the ASIC database (12). syncd, running in the Syncd container, subscribes to the ASIC state and receives the notification (13). The notification identifies the ASIC_DB entry that has changed. In this example, the relevant object is the existing SAI_OBJECT_TYPE_PORT object for Ethernet0:

ASIC_STATE:SAI_OBJECT_TYPE_PORT:oid:0x1000000000002

syncd retrieves the corresponding data from ASIC_DB and deserializes the Redis representation into the SAI operation that must be performed (14). For the administrative-state change in this example, the operation corresponds to setting the SAI attribute: SAI_PORT_ATTR_ADMIN_STATE = true. syncd then invokes the corresponding standard SAI API operation. The SAI API provides the vendor-independent interface between SONiC and the vendor-specific SAI implementation. The vendor SAI implementation receives the SAI operation and translates it into the vendor-specific operations required by the underlying Software Development Kit (SDK) and ASIC driver.

The vendor SDK and ASIC driver then apply the requested configuration to the hardware ASIC (15). After the operation has been completed, the result is returned through the SAI implementation to syncd, allowing SONiC to determine whether the SAI operation was successful (16).

 Figure 5-8: Updating Redis Databases: Port State Change - from ASIC_DB to Hardware ASIC.

 

Processing Ethernet0 State from the Linux Kernel to STATE_DB

Figure 5-9 illustrates the final part of the Ethernet0 state-processing path. After the Ethernet0 interface state has been applied to the Linux networking subsystem, the Linux kernel reports link-state information through RTNETLINK (17). The portsyncd, running in the SWSS container, listens for relevant RTNETLINK link events and processes the information before publishing the resulting port state to STATE_DB.

The Linux kernel sends an RTM_NEWLINK message when information about a network interface is created or changed. RTM_NEWLINK belongs to the NETLINK_ROUTE family and carries information about a network link, including the interface index, interface flags, and additional attributes such as the interface name, MAC address, and MTU.

User-space applications receive RTNETLINK events through a netlink socket. The socket can subscribe to one or more rtnetlink multicast groups. For link-related events, the relevant group is the link multicast group, commonly represented by RTMGRP_LINK in the Linux networking APIs. A process that joins this group receives link notifications generated by the kernel for the interfaces covered by the subscription.

portsyncd has a netlink socket subscribed to the relevant link-event group. Therefore, when the Linux kernel generates an RTM_NEWLINK notification for Ethernet0, the message is delivered to the portsyncd process through the netlink socket.

For Ethernet0, the received message contains information such as the interface name, interface index, interface flags, MAC address, operational state, master, and interface type. In this SONiC-VM example, the interface is identified as Ethernet0, has interface index 1, and its operational state is UP.

portsyncd parses the received netlink message and extracts the information required to represent the port state in SONiC. It performs basic validation and filtering of the received link information, including determining whether the event corresponds to a SONiC-managed port (18). It does not perform the same type of configuration validation performed by components such as portmgrd or PortOrch. Its primary role here is to translate Linux link-state information into the SONiC port-state representation.

After processing the netlink information, portsyncd publishes the resulting port-state data through the Redis database interface (19). Redis stores the data in STATE_DB, where it becomes available to other SONiC components that consume port-state information (20).

For Ethernet0, the resulting STATE_DB entry is stored under PORT_TABLE|Ethernet0. The entry contains both configuration-related and operational information. For example, admin_status is up, while netdev_oper_status is also up. The oper_speed field reports the current operational speed as 25000, corresponding to 25 Gb/s.

Note: STATE_DB provides a shared repository of operational state that can be consumed by other SONiC components and applications, such as LLDP and SNMP, without requiring each component to obtain the state directly from the Linux kernel or hardware.

 

Figure 5-9: Updating Redis Databases: Port State Change - from Hardware ASIC to STATE_DB.

This completes the state-reporting path from the Linux networking subsystem back into the SONiC database architecture.

 

Summary

The Ethernet0 port state change demonstrates how a configuration change travels through the different layers of the SONiC architecture. The process starts when the SONiC CLI changes the admin_status of PORT|Ethernet0 in CONFIG_DB. Redis notifies portmgrd, which retrieves the current port configuration, processes it, and writes the corresponding PORT_TABLE:Ethernet0 entry to APPL_DB.

 

orchagent receives the APPL_DB notification and passes the port configuration to PortOrch. PortOrch processes the configuration and determines the required SAI operation. Through libsairedis, the SAI operation is serialized and written through Redis to ASIC_DB, where the existing SAI_OBJECT_TYPE_PORT object for Ethernet0 is updated with the corresponding SAI attributes.

 

syncd, running in the Syncd container, receives the ASIC_DB notification and retrieves the SAI operation. It deserializes the Redis representation and invokes the standard SAI API. The vendor SAI implementation translates the SAI operation into vendor-specific operations that are passed to the vendor SDK and ASIC driver, which ultimately applies the configuration to the hardware ASIC.

 

The resulting interface state is also reflected on the Linux side. The Linux kernel reports link-state changes through RTNETLINK messages. portsyncd, running in the SWSS container, receives the relevant link notification through its netlink subscription, processes the Linux interface information, and publishes the resulting port state to STATE_DB.

 

The complete process therefore demonstrates that a SONiC port state change is not a single operation between a CLI command and the ASIC. The information is progressively processed and represented at different layers:

 

CONFIG_DB → portmgrd → APPL_DB → orchagent/PortOrch → libsairedis → ASIC_DB → syncd → SAI/vendor SDK → hardware ASIC

 

while the resulting Linux interface state follows a complementary path:

 

Linux kernel → RTNETLINK → portsyncd → STATE_DB

Together, these paths show how SONiC separates configuration, ASIC programming, and operational state reporting, while Redis provides the database and notification mechanism connecting the major SONiC components.

 

Figure 5-10: Complete Pipeline for Port State Change.

SONiC Deep Dive: Configuring VLAN 10 from CLI to ASIC

 

Introduction

In this chapter, we examine what happens under the hood when we configure a Layer-2 VLAN on a SONiC switch, enable two host-facing interfaces, and associate them with the previously created VLAN as untagged access ports. Figure 5-1 illustrates the conceptual configuration in which Host-1 and Host-2 are connected to interfaces Eth1/1 and Eth1/2, respectively. Both interfaces are members of VLAN 10, which at this stage functions as a Layer-2 broadcast domain. The host-facing interfaces are single-lane 25-Gigabit Ethernet interfaces.

 

We begin by creating VLAN 10 and examining the complete SONiC processing sequence, from the user's VLAN configuration to ASIC programming. Next, we study what happens when the interfaces are enabled and associated with VLAN 10. Finally, we verify that Host-1 and Host-2 have IP connectivity through Leaf-1. Although this is a very basic configuration example, many SONiC components participate in the process. The database examples presented in this chapter are taken from the lab environment. The communication between processes is explained at a conceptual level because the focus is on SONiC operation rather than the underlying Linux communication mechanisms.

Figure 5-1: Host Connectivity.

Step 1: Configure Vlan 10

 

Figure 5-2 depicts the conceptual sequence of processes and events that occur when the administrator creates a Layer-2 VLAN on a SONiC switch. In the SONiC distribution used in this book, VLAN 10 is created by entering the SONiC command config vlan add 10 in a Linux Bash shell (phase 1). The command updates CONFIG_DB (phase 2).

 

From GONFIG_DB to APPL_DB

When CONFIG_DB is updated, the Redis server generates a notification indicating that the VLAN table has changed. The notification contains information about the newly created VLAN 10.

 

The vlanmgrd daemon, which belongs to the Configuration Manager component in the SWSS container, subscribes to the VLAN table in CONFIG_DB. Therefore, it receives the notification over a pre-established Inter-Process Communication (IPC) channel implemented as a UNIX domain socket (phase 3). The Process Identifiers (PIDs) shown in Figure 5-2 are conceptual and are included only to identify the communicating processes. For example, the redis-server and vlanmgrd daemons each run as separate Linux processes and therefore have their own unique PID. Communication between the processes takes place through a UNIX domain socket, whose endpoints are represented by file descriptors (FDs) owned by the communicating processes.

 

In the example shown in Figure 5-2, PID 1329 identifies the redis-server process, while FD 411 identifies the UNIX domain socket endpoint owned by that process. Likewise, PID 1845 identifies the vlanmgrd process, while FD 7 identifies the corresponding UNIX domain socket endpoint owned by vlanmgrd. The socket connection is therefore established between the socket endpoints represented by the file descriptors, while the PIDs simply identify the processes that own those endpoints.

 

After receiving the notification, vlanmgrd obtains the configuration associated with the updated VLAN entry (phase 4). Depending on the SONiC distribution and implementation, the required information may be available directly in the notification message or it may be read from CONFIG_DB. In the example shown in Figure 5-2, vlanmgrd reads the required information from the notification message.

 

Next, vlanmgrd converts the received configuration into the format expected by APPL_DB and publishes the corresponding entry to the Redis server using the existing UNIX domain socket connection (phase 5). Translation is required because the Redis server does not modify or translate the information it receives. Its role is simply to store the received data in the selected database. After receiving the translated entry from vlanmgrd, the Redis server stores it in APPL_DB (phase 6).

Figure 5-2: Updating Redis Databases - from CONFIG_DB to APPL_DB.

 

Verifying CONFIG_DB and APPL_DB

 

The Redis server used by SONiC maintains several logical databases, each serving a specific role in the processing pipeline. Separating configuration, operational, and hardware-related information into different databases allows SONiC components to exchange only the information relevant to their function. Each database is organized into tables. A table contains one or more keys, and each key stores one or more field-value pairs that define the attributes of the corresponding object.

 

Example 5-1 shows the VLAN table entry for VLAN 10 in CONFIG_DB, while Example 5-2 shows the corresponding VLAN object in APPL_DB.

 

The CONFIG_DB database stores the configuration requested by the administrator. It represents the desired state of the system and therefore contains only the information required to define the object. In this example, the VLAN object contains only the VLAN identifier (vlanid) that was specified by the config vlan add 10 commands.

 

The APPL_DB database stores operational objects that have been prepared for further processing by downstream SONiC components. When `vlanmgrd` receives the configuration from CONFIG_DB, it validates the information and translates it into the format expected by APPL_DB. As a result, the APPL_DB entry contains additional field-value pairs describing the operational state of the VLAN, including the administrative status, operational status, MAC address, MTU, operational MTU, and the time of the last state change. These attributes provide the information required by subsequent SONiC components to continue processing the VLAN configuration.

 

 

admin@sonic:~$ sonic-db-dump -n CONFIG_DB --pretty -k 'VLAN|Vlan10'

{

  "VLAN|Vlan10": {

    "expireat": 1785914956.0346863,

    "ttl": -0.001,

    "type": "hash",

    "value": {

      "vlanid": "10"

    }

  }

Example 5-1: CONFIC_DB - Vlan Table Key VLAN|Vlan10.

 

admin@sonic:~$ sonic-db-dump -n APPL_DB --pretty -k 'VLAN_TABLE:Vlan10'

{

  "VLAN_TABLE:Vlan10": {

    "expireat": 1785915016.382373,

    "ttl": -0.001,

    "type": "hash",

    "value": {

      "admin_status": "up",

      "last_change": "1785914543",

      "mac": "0c:9a:32:79:00:0a",

      "mtu": "9100",

      "oper_mtu": "9100",

      "oper_status": "down"

    }

  }

Example 5-2: APPL_DB - Vlan Table Key VLAN_TABLE:Vlan10.

 

Note: The output generated by the sonic-db-dump utility includes the metadata fields expireat, ttl, and type. These describe the Redis object rather than the VLAN configuration itself. The expireat and ttl fields indicate whether the object expires, while type identifies the Redis data structure used to store the object. In these examples, the value hash indicates that the VLAN object is stored as a Redis hash containing multiple field-value pairs.

From APPL_DB to ASIC_DB

 

Figure 5-3 depicts the conceptual processing sequence that takes place after the Redis server updates the VLAN_TABLE in APPL_DB. Once the update has been stored, the Redis server generates a notification describing the change. Because orchagent subscribes to the VLAN_TABLE in APPL_DB, it receives the notification (phase 7) and retrieves the corresponding VLAN object from APPL_DB (phase 8).

 

Within orchagent, the VLAN object is processed by VlanOrch, an orchestration component responsible for VLAN objects. VlanOrch invokes the standard SAI API by calling sai_create_vlan(), passing the VLAN identifier as a parameter (phase 9). The SAI API call is then serialized by libsairedis into the Redis representation used for ASIC objects (phase 10). This translation is necessary because the Redis server does not interpret or translate SAI API calls. Its role is simply to store the information it receives in the appropriate database.

 

After the SAI request has been translated, orchagent sends the resulting Redis object to the Redis server using the existing UNIX domain socket connection (phase 11). The Redis server stores the received object in ASIC_DB (phase 12).

 

Unlike CONFIG_DB and APPL_DB, which identify objects using descriptive names such as Vlan10, ASIC_DB represents hardware objects by assigning each one a unique Object Identifier (OID). From the ASIC's perspective, every hardware resource is represented as an object. Consequently, the ASIC does not identify the VLAN by the name Vlan10; instead, it refers to the VLAN by its assigned OID. In the example shown in Figure 5-3, VLAN 10 is represented by the object oid:0x26000000000a65.

Figure 5-3: Updating Redis Databases - from APPL_DB to ASIC_DB.

Verifying ASIC_DB

 

Example 5-3 shows the VLAN objects stored in ASIC_DB. The wildcard character (*) at the end of the sonic-db-dump command is used because the Object Identifier (OID) assigned to VLAN 10 is not known in advance. Therefore, the command displays all VLAN objects currently stored in ASIC_DB.

Notice that the default VLAN (VLAN 1) is also present. Each VLAN is represented by a separate ASIC object whose key contains a unique OID. The actual VLAN number is not encoded in the key itself but is stored as the attribute SAI_VLAN_ATTR_VLAN_ID. In this example, the object with the key ASIC_STATE:SAI_OBJECT_TYPE_VLAN:oid:0x26000000000a65 contains the attribute SAI_VLAN_ATTR_VLAN_ID with the value 10, indicating that this ASIC object represents VLAN 10.

 

admin@sonic:~$ sonic-db-dump -n ASIC_DB --pretty -k 'ASIC_STATE:SAI_OBJECT_TYPE_VLAN:*'

{

  "ASIC_STATE:SAI_OBJECT_TYPE_VLAN:oid:0x26000000000955": {

    "expireat": 1785915438.5691075,

    "ttl": -0.001,

    "type": "hash",

    "value": {

      "NULL": "NULL",

      "SAI_VLAN_ATTR_VLAN_ID": "1"

    }

  },

  "ASIC_STATE:SAI_OBJECT_TYPE_VLAN:oid:0x26000000000a65": {

    "expireat": 1785915438.5690937,

    "ttl": -0.001,

    "type": "hash",

    "value": {

      "SAI_VLAN_ATTR_VLAN_ID": "10"

    }

  }

}

Example 5-3: ASIC_DB - SAI_OBJECT_TYPE_VLAN.

 

Programming Vlan 10 into Hardware ASIC

Figure 5-4 illustrates the final stage of the VLAN creation process, where VLAN 10 is programmed into the hardware ASIC. After the Redis server stores the SAI_OBJECT_TYPE_VLAN object for VLAN 10 in ASIC_DB, it generates a Redis notification indicating that the ASIC database has been updated (phase 13).

 

The syncd daemon, running in the Syncd container, subscribes to ASIC_STATE: SAI_OBJECT_TYPE_VLAN and therefore receives the notification. It then retrieves the corresponding ASIC object from ASIC_DB (phase 14). Next, syncd deserializes the Redis representation back into the corresponding SAI operation and invokes the standard SAI API. The request is then forwarded to the vendor SAI implementation, which passes it to the vendor Software Development Kit (SDK) (phase 15).

 

The vendor SDK translates the standard SAI operation into the vendor-specific commands required by the hardware ASIC. These commands are then executed by the vendor ASIC driver, which programs VLAN 10 into the hardware (phase 16). After the operation has been completed successfully, the vendor SAI implementation returns the result to syncd, completing the VLAN creation process.

 

Note: Figure 5-4 shows only the Object Identifier (OID) generated by SONiC. Internally, this identifier represents a Virtual Object Identifier (VID). When the object is programmed into the hardware ASIC, the vendor SAI implementation assigns a hardware-specific Real Object Identifier (RID). syncd maintains the mapping between VIDs and RIDs so that subsequent SAI operations can reference the correct hardware object.

 

Example 5-4 shows the VLAN status using the SONiC CLI. Although VLAN 10 has now been programmed into the hardware ASIC, its status is still Inactive because no switch interfaces have yet been configured as members of the VLAN.

Figure 5-4: Updating ASIC- from ASIC_DB to Hardware ASIC.

 

Example 5-4 depicts how the Vlan 10 status using sonic CLI. The status is still Inactive because we haven’t yet configugre any interface as a member of Vlan10.

 

 

sonic# show Vlan

Q: A - Access (Untagged), T - Tagged

NUM        Status      Q Ports            Autostate   Dynamic

10         Inactive                        Enable

Example 5-4: SONIC-CLI: VLAN 10.

 

Summary

 

Figure 5-5 summarizes the complete processing sequence through which VLAN 10 is created and programmed into the switch ASIC.

 

The process begins when the network administrator creates VLAN 10 by entering the SONiC command config vlan add 10. The command updates CONFIG_DB with the user-defined VLAN configuration. After the update, the Redis server generates a notification and sends it to the vlanmgrd daemon in the SWSS container over the existing UNIX domain socket connection.

 

The vlanmgrd daemon retrieves the updated VLAN configuration, validates it, and translates it into the operational format expected by APPL_DB. The translated object is then published to the Redis server, which stores it in APPL_DB and generates another notification indicating that the VLAN_TABLE table has been updated.

 

The orchagent process subscribes to the APPL_DB VLAN_TABLE table and receives the notification. It retrieves the updated VLAN object and forwards it to the VlanOrch orchestration component. VlanOrch invokes the standard SAI API by calling sai_create_vlan(), passing the VLAN identifier as a parameter. The SAI request is then serialized by libsairedis (not shown in figure) into the Redis representation used for ASIC objects and stored in ASIC_DB through the Redis server.

 

After ASIC_DB has been updated, the Redis server notifies the syncd daemon running in the Syncd container. The syncd daemon retrieves the ASIC object from ASIC_DB, deserializes it back into the corresponding SAI operation, and forwards the request to the vendor SAI implementation. The vendor SAI implementation passes the request to the vendor Software Development Kit (SDK), which translates the standard SAI operation into vendor-specific commands. These commands are executed by the vendor ASIC driver, programming VLAN 10 into the hardware ASIC. After the operation completes successfully, the result is returned to syncd, completing the VLAN creation process.

 

This processing sequence demonstrates the modular architecture of SONiC. Each software component is responsible for a specific stage of the configuration pipeline, while the Redis databases provide a common mechanism for exchanging information between the components. This separation enables SONiC to maintain a clear distinction between user configuration, operational processing, and hardware programming.

Figure 5-5: The Complete Process: Vlan 10 from SONiC CLI to Hardware ASIC.

Note: The detailed processing sequence presented in this chapter establishes the baseline for understanding SONiC operation. Unless additional details are required, the remaining chapters use the simplified processing sequence shown in Figure 5-5.