Will You Ever Get ROI with Transitioning to Open-Source?

Download PDF

Community SONiC Porting: Make This Open NOS Work on Your Hardware

December 1, 2023
Community SONiC Porting: Make This Open NOS Work on Your Hardware

Explore the intricacies of enabling Community SONiC on networking hardware. In this article, we will guide you through the installation specifics and address common challenges to ensure a seamless integration. As an active member of the SONiC project, PLVision leverages its expertise to broaden the range of Community SONiC use cases. Benefit from our experience and discover how to make your hardware compatible with this popular open NOS.

Contents
1. Porting SONiC to networking hardware: turning it into an asset, not a headache
2. The installation process to make SONiC work on your hardware
3. The next essential steps to make SONiC support networking devices
4. Understanding challenges to enable Community SONiC on your hardware

Porting SONiC to networking hardware: turning it into an asset, not a headache

Unlike classic proprietary NOSes, with their license fees and dependency on the vendor’s innovation roadmap for the product, the open-source SONiC allows you to gain substantial control over system functionality. It runs on a variety of network switches and routers and is not tied to any specific vendor or ASIC. SONiC is widely embraced in the industry, yet harnessing its potential for your business necessitates the skill of transforming this NOS into a valuable asset rather than a potential headache.

Let’s explore a case involving global networking hardware provider that needed to port SONiC on their platforms. In exploring the process journey, they found that porting would evolve into a regular task, requiring frequent synchronizations with upstream due to the dynamic nature of SONiC. Recognizing that the NOS serves as the crucial link between users and hardware, the company understood that any malfunctions in the new product could significantly impact their brand, emphasizing the importance of guaranteeing reliability to maintain customer satisfaction and uphold the company’s reputation. Now, the crucial question emerges: how can one ensure a smooth and fast porting process? 

Enabling SONiC on a new platform requires an understanding of its architecture and installation details, as well as a keen awareness of the platform software and drivers supported by OEM and ODM vendors. As we delve further into this article, we’ll explore these aspects in detail. 

The installation process to make SONiC work on your hardware

The SONiC project leverages the Open Network Installation Environment (ONIE) to seamlessly deploy the NOS image onto hardware. ONIE, a Linux-based initiative of the Open Compute Project (OCP), plays a pivotal role in orchestrating the installation process. 

The NOS installation follows a well-defined workflow, as shown in Figure 1. It begins with the switch’s low-level bootloader initializing the hardware, culminating in ONIE activation. ONIE serves as a crucial component, which essentially combines a Linux kernel with BusyBox on top. Following the configuration of the management or out-of-band interface (OOB), ONIE detects and initiates the installation program provided by the NOS.

SONiC_porting_The first boot–up processFigure 1. The first bootup process

ONIE offers various methods to locate its installer, but the preferred method for downloading images is HTTP. This method ensures reliable performance, particularly for large image sizes, and eliminates the need for physical access to hardware, as is the case with a USB stick. 

ONIE isn’t triggered during every system boot. Following the initial installation, subsequent reboots directly involve the NOS, bypassing the ONIE phase. This process is shown below:

SONiC_porting_Boot–up process with already installed NOSFigure 2. Bootup process with pre-installed NOS

Therefore, ONIE is essential for managing SONiC images on a new platform. In instances where OEM and ODM vendors lack ONIE, it becomes the initial step in the SONiC porting process.

The next essential steps to make SONiC support networking devices

Consider a scenario where we have ONIE for the porting platform, equipped with the necessary drivers for SONiC installation, along with a library for the ASIC managed by the SAI in the NOS. This library is commonly referred to as the SAI library. 

Within SONiC’s architecture, diverse platform daemons reside in the pmon container, responsible for retrieving data from peripheral devices and executing write operations on them. These processes may include tasks such as reading temperature data from thermal sensors and dynamically adjusting fan speeds. The core concept of pmon’s daemons involves posting platform data from peripheral devices to the Redis database. 

For the continuous updating of data values (such as PSU state, fan speed, temperature, etc.), daemons subscribe to specific entries in the database, respond to requests, and call the platform API accordingly. The snmp_subagent collects information from SONiC databases and sends it to the master-agent (snmpd). These intricate interactions are shown in Figure 3. 

Platform_interactionsFigure 3. Platform interactions

The appropriate platform drivers are installed during the initial boot of the device, triggered upon the identification of the device’s SKU. Device-specific platform drivers are added to SONiC as .deb packages and should contain initialization and deinitialization methods. 

The SONiC Platform API follows an object-oriented structure, designed with abstract base classes. For new platform devices, these classes need implementation and inclusion in the sonic-platform package. To facilitate its integration, the file should be installed on the host operating system and copied to the device folder, named according to the ONIE platform string. 

There are CLI commands to manage platform peripheral devices using Python 3 utilities. Some of them may necessitate root permissions when executed from the host OS. This is a generic CLI of SONiC, but the vendor’s specific CLI to configure and diagnostic of peripheral devices might be implemented additionally.

To enable synchronization between the hardware ASIC and SONiC software, the syncd container leverages the SAI library from the chip vendor. Porting the syncd container in SONiC involves adapting and configuring the SAI library tailored to a specific ASIC or switch platform.

sonic_architecture

Figure 4.  Syncd container placement in SONiC System Architecture

The SWSS (SWitch State Service) container acts as an orchestration agent or control plane manager in SONiC. It oversees a redis database, storing network state information and providing an interface for other SONiC components to access and update the database. It communicates with syncd to synchronize the network state between SONiC software and the underlying hardware. 

In essence, porting syncd to a new platform bridges the gap between control plane applications (containers) and the SAI library. This sets the groundwork for applications such as LLDP or BGP to function seamlessly.

Understanding challenges to enable Community SONiC on your hardware

Porting any network operating system to a new device is a complex task which demands a deep understanding of hardware architecture and software programming. Handling this process in-house can result in product release delays. It may require the training of your engineers or hiring new ones with the necessary expertise, which can be both costly and time-consuming. 

There is another complexity to consider – contributing to the upstream. This entails actively submitting regular updates and ensuring that your product aligns with the evolving standards and features embraced by the global SONiC community. Picture it as a recurring commitment: each time you update your product, you will need to navigate the process of contributing back to the community.

With its hands-on expertise and strong presence in the SONiC project, PLVision can make SONiC enablement effortless for you, ensuring full compatibility between Community SONiC and your hardware.

Explore our SONiC porting offering and contact us to figure out the first steps to make your hardware compatible with this NOS.

Conclusion

Nowadays, SONiC enablement has become a must-have for any OEM and ODM vendor looking to provide efficient options to users. To accomplish effective integration, it is necessary to possess a comprehensive understanding of SONiC’s architecture, installation specifics, and alignment with platform software and drivers. Successful porting enables efficient management of peripheral devices and interactions within SONiC’s architecture, enhancing the flexibility and functionality of networking equipment.

If you are looking for a productive way to swiftly achieve your business goals and fully embrace the benefits of SONiC, it is best to save yourself time and leverage the expertise of professionals who have been successfully working with this NOS for years. Ultimately, optimizing your resources, streamlining procedures, and ensuring your product remains competitive within your overall business strategy is key.

Oleksandr Kholodnyi