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).
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.
No comments:
Post a Comment