Why Choose SONiC for Your Network

At the time of this writing, SONiC utilizes the following Docker containers to compartmentalize its core functionalities:

• Teamd
• Pmon
• Snmp
• Dhcp-relay
• Lldp
• Bgp
• Database
• Swss
• Syncd

Teamd Container:

• Runs Link Aggregation functionality (LAG) in SONiC devices. “teamd” is a Linux-based open-source implementation of LAG protocol. “teamsyncd” process allows the interaction between “teamd” and south-bound subsystems.

Pmon Container:

• In charge of running “sensord”, a daemon used to periodically log sensor readings from hardware components and to alert when an alarm is signaled. Pmon container also hosts “fancontrol” process to collect fan-related state from the corresponding platform drivers.

Snmp Container:

• Hosts snmp features.
• Processes:
  • Snmpd: Actual snmp server in charge of handling incoming snmp polls from external network elements.
  • Snmp-agent (sonic_ax_impl): This is SONiC’s implementation of an AgentX snmp subagent. This subagent feeds the master-agent (snmpd) with information collected from SONiC databases in the centralized redis-engine.

Dhcp-relay Container:

• The dhcp-relay agent enables the relay of DHCP requests from a subnet with no DHCP server, to one or more DHCP servers on other subnets.

Lldp Container:

• As its name implies, this container hosts lldp functionality.
• Processes:
  • Lldp: Actual lldp daemon featuring lldp functionality. This is the process establishing lldp connections with external peers to advertise/receive system capabilities.
  • Lldp_syncd: Process in charge of uploading lldp’s discovered state to the centralized system’s message Infrastructure (redis-engine). By doing so, lldp state will be delivered to applications interested in consuming this information (e.g. snmp).
  • Lldpmgr: Process provides incremental-configuration capabilities to lldp daemon; It does so by subscribing to STATE_DB within the redis-engine.

Bgp Container:

• Runs one of the supported routing-stacks: Quagga or FRR. Even though the container is named after the routing-protocol being used (bgp), in reality, these routing-stacks can run various other protocols (such as ospf, isis, ldp, etc).
• BGP container functionalities are broken down as follows:
  • bgpd: regular bgp implementation. Routing state from external parties is received through regular tcp/udp sockets, and pushed down to the forwarding-plane through the zebra/fpmsyncd interface.
  • zebra: acts as a traditional IP routing-manager; that is, it provides kernel routing-table updates, interface-lookups and route-redistribution services across different protocols. Zebra also takes care of pushing the computed FIB down to both kernel (through netlink interface) and to south-bound components involved in the forwarding process (through Forwarding-Plane-Manager interface –FPM–).
  • fpmsyncd: small daemon in charge of collecting the FIB state generated by zebra and dumping its content into the Application-DB table (APPL_DB) seating within the redis-engine.

Database Container:

• Hosts the redis-database engine. Databases held within this engine are accessible to SONiC applications through a UNIX socket exposed for this purpose by the redis-daemon. These are the main databases hosted by the redis engine:
  • APPL_DB: Stores the state generated by all application containers — routes, next-hops, neighbors, etc. This is the south-bound entry point for all applications wishing to interact with other SONiC subsystems.
  • CONFIG_DB: Stores the configuration state created by SONiC applications — port configurations, interfaces, vlans, etc.
  • STATE_DB: Stores “key” operational state for entities configured in the system. This state is used to resolve dependencies between different SONiC subsystems.
  • ASIC_DB: Stores the necessary state to drive asic’s configuration and operation — state here is kept in an asic-friendly format to ease the interaction between syncd (see details further below) and asic SDKs.
  • COUNTERS_DB: Stores counters/statistics associated to each port in the system. This state can be utilized to satisfy a CLI local request, or to feed a telemetry channel for remote consumption.

Swss Container:

• The Switch State Service (SwSS) container comprises of a collection of tools to allow an effective communication among all SONiC modules. If the database container excel at providing storage capabilities, Swss mainly focuses on offering mechanisms to foster communication and arbitration between all the different parties.
• Swss also hosts the processes in charge of the north-bound interaction with the SONiC application layer. The exception to this, as previously seen, is fpmsyncd, teamsyncd and lldp_syncd processes which run within the context of the bgp, teamd and lldp containers respectively. Regardless of the context under which these processes operate (inside or outside the swss container), they all have the same goals: provide the means to allow connectivity between SONiC applications and SONiC’s centralized message infrastructure (redis-engine). These daemons are typically identified by the naming convention being utilized: *syncd.

Portsyncd:

• Listens to port-related netlink events. During boot-up, portsyncd obtains physical-port information by parsing system’s hardware-profile config files.

Intfsyncd:

• Listens to interface-related netlink events and push collected state into APPL_DB. Attributes such as new/changed ip-addresses associated to an interface are handled by this process.

Neighsyncd:

• Listens to neighbor-related netlink events triggered by newly discovered neighbors as a result of ARP processing. Attributes such as the mac-address and neighbor’s address-family are handled by this daemon. This state will be eventually used to build the adjacency-table required in the data-plane for L2-rewrite purposes.

Teamsyncd:

• Previously discussed — running within teamd docker container. As in the previous cases, obtained state is pushed into APPL_DB.

Fpmsyncd:

• Previously discussed — running within bgp docker container. Again, collected state is injected into APPL_DB.

Lldp_syncd:

• Also previously discussed — running within lldp docker container.

Syncd container:

• In a nutshell, syncd’s container goal is to provide a mechanism to allow the synchronization of the switch’s network state with the switch’s actual hardware/ASIC. This includes the initialization, the configuration and the collection of the switch’s ASIC current status.
• These are the main logical components present in syncd container:
  • Syncd: Process in charge of executing the synchronization logic mentioned above. At compilation time, syncd links with the ASIC SDK library provided by the hardware-vendor, and injects state to the ASICs by invoking the interfaces provided for such effect. Syncd subscribes to ASIC_DB to receive state from SWSS actors, and at the same time registers as a publisher to push state coming from the hardware.
  • SAI API: The Switch Abstraction Interface (SAI) defines the API to provide a vendor-independent way of controlling forwarding elements, such as a switching ASIC, an NPU or a software switch in a uniform manner.
  • ASIC SDK: Hardware vendors are expected to provide a SAI-friendly implementation of the SDK required to drive their ASICs. This implementation is typically provided in the form of a dynamic-linked-library which hooks up to a driving process (syncd in this case) responsible of driving its execution.