SONiC Architecture

SONiC is an open-source Network Operating System (NOS) based on Debian Linux distribution that runs on network devices such as routers and switches. SONiC offers a full suite of network functionality, like BGP, LLDP, and SNMP to name a few. SONiC includes networking software components that are required to have a fully functional L3 device. It allows cloud operators to share the same software stack across hardware from multiple vendors. Cisco is part of this ecosystem harnessing the innovation in Cisco Silicon One Q100/Q200 ASIC, a unified silicon architecture on the Cisco 8000 series routers. With the unique ability of the Cisco Silicon One ASIC to enable Ethernet or IP-based packet forwarding within the chassis, the ASIC can be configured in either network mode or fabric mode.

SONiC uses Switch Abstraction Interface (SAI) API version 1.7.1 for release 202012. The SAI API defines the API to provide a mechanism to control forwarding elements, such as a switching ASIC, an NPU or a software switch in a uniform manner. For more information about SAI APIs, refer the Github repository.

Integration with Peripheral Components

Integration with the peripheral hardware is accomplished in two ways: read data to obtain the device status or write an operation to modify the device state. For example, in an SFP transceiver, the read operation includes checking the presence of transceiver, EEPROM data cable type, vendor, part number, and transceiver interrupt (plug or unplug) events. The write operations include resetting the transceiver and enabling or disabling the low-power mode.

Cisco delivers the following components to facilitate integration with the peripheral components of the router:

• Board Support Packages (BSP): Compiles all the kernel modules that expose the functionality of the peripheral hardware.
• Python plug-ins: SONiC interacts with the exposed peripheral hardware using standard python plug-ins.

SONiC is installed on a fixed form factor chassis to address a broad range of network ecosystem. One SONiC instance runs on the fixed system.

You can install SONiC on the following fixed form factor chassis on the Cisco 8000 series routers.

The following image illustrates the SONiC architecture on Cisco 8000 series routers:

SONiC utilizes a well-defined API called Switch Abstraction Interface (SAI) for the hardware abstraction layer. The operating system uses the SAI API to interact with the underlying hardware such as ASIC drivers, network drivers, and platform drivers. The layers integrate into the peripheral hardware components such as fans, power modules, optic sensors, system EEPROM on the Cisco 8000 series router.

Each block in the architecture is a docker container: dhcp-relay container: Enables the relay of DHCP requests from a subnet with no DHCP server, to one or more DHCP servers on other subnets.

pmon container: Logs sensor readings from hardware components.

• fancontrol: Collects fan-related state from the corresponding platform drivers.
• sensord: Reads and logs sensor readings from hardware components, and alerts when an alarm is triggered.

snmp container: Hosts the SNMP features.

• snmpd: Server that handles incoming SNMP polls from external network elements.
• snmp_subagent: Inputs the snmpd server with information that is collected from SONiC databases in the centralized Redis engine.

lldp container: Hosts LLDP functionality.

• lldpd: Establishes LLDP connections with external peers to advertise or receive system capabilities.
• lldpmgrd: Provides incremental-configuration capabilities to LLDP daemon.
• lldp_syncd: Uploads the discovered state of LLDP to the centralized message infrastructure in the Redis engine. By doing so, the LLDP state is delivered to applications such as SNMP that consume this information.

bgp container: Runs the supported routing stacks such as FRR. Although the container is named after the BGP routing protocol, these routing stacks can run various other protocols such as OSPF, IS-IS, LDP, and so on.

• bgpd: Implements BGP functionality. The routing state from external entities is received through regular TCP/UDP sockets, and pushed to the forwarding plane through the zebra and fpmsyncd interfaces.
• zebra: Acts as an IP routing manager that provides routing table updates for the kernel, interface-lookups, and route-redistribution services across different protocols. It pushes the computed FIB to kernel through Netlink interface, and to south-bound components involved in the forwarding process through Forwarding Plane Manager (FPM) interface.
• fpmsyncd: Collects the FIB state that is generated by zebra and dumps its content into the APPL_DB table in the Redis server.

teamd container: Allows interaction between Link Aggregation functionality (LAG) and south-bound subsystems.

• team: Implements LAG protocol.
• teamsyncd: Pushes the obtained state into the APPL_DB.

swss container: Switch State Service (swss) container is a suite of tools to coordinate communication among all the SONiC modules and the Redis engine. It hosts the processes incharge of the north-bound interaction with the SONiC application layer. The exception to this process is the fpmsyncd, teamsyncd and lldp_syncd processes that run within the context of bgp, teamd, and lldp containers respectively.

• portsyncd: Listens to port-related Netlink events. During bootup, portsyncd obtains physical port information by parsing hardware profile config files. It pushes all the collected state into APPL_DB. Attributes such as port-speeds, lanes and MTU, and also injects the state into the STATE_DB.
• intfsyncd: Listens to interface-related Netlink events and push collected state into APPL_DB. It handles the attributes such as new and changed ip-addresses that are associated to an interface.
• neighsyncd: Listens to neighbor-related Netlink events triggered by newly discovered neighbors because of ARP processing. It handles the attributes such as the MAC address and the address family of the neighbor.
• orchagent: Extracts all the relevant state that is injected by the syncd daemons, processes the information, and pushes data toward the south-bound interface, which is a database within the Redis engine. It operates both as a consumer (state coming from the APPL_DB), and also as a producer (state pushed into ASIC database).
• intfmgrd: Responds to state arriving from APPL_DB, STATE_DB and CONFIG_DB to configure interfaces in the Linux kernel.
• vlanmgrd: Responds to state arriving from APPL_DB, STATE_DB and CONFIG_DB to configure VLAN interfaces in the Linux kernel.

database container: Hosts the database for Redis engine. Databases that are held within this engine are accessible to SONiC applications through a UNIX socket exposed for this purpose by the Redis daemon.

The Redis engine hosts the following main databases:

• APPL_DB: Stores the state that is generated by all application containers such as routes, next-hops, neighbors, and so on . This database is the south-bound entry point for all applications to interact with other SONiC subsystems.
• CONFIG_DB: Stores the configuration state that is created by SONiC applications such as port configurations, interfaces, vlans, and so on.
• STATE_DB: Stores key operational state for entities that are configured in the system. This state is used to resolve dependencies between different SONiC subsystems. For example, a LAG port channel (defined by teamd submodule) can potentially refer to physical ports that may or may not be present in the system.
• ASIC_DB: Stores the necessary state to drive ASIC configuration and operation.
• COUNTERS_DB: Stores counters or statistics that are associated to each port in the system.

syncd container: Contains the Switch Abstraction Interface (SAI) library. All SAI programming requests are initiated by syncd, usually in response to Redis from various SONiC processes. It is the primary SONiC entry point into platform-specific services. The syncd process programs the networking ASIC through the SAI API. Cisco provides a SAI-friendly implementation of the ASIC SDK. Both the north-bound SAI API and ASIC SDK are coupled into a single shared library that is called the libsai.so.