5 things to consider before trying SoNiC

Open networking has helped the hyper-scale cloud providers build and manage their infrastructures. Instead of solely using integrated hardware and software solutions from vendors, they have developed their own software running on switching hardware from the Open Compute Project. SoNiC, originally developed by Microsoft, is the most well known Opensource switching software with the broadest support of hardware and ASIC’s. As its also deployed in Azure, its a proven platform and perhaps the first real candidate for Opensource Network Operating System.

SoNiC unlocks countless opportunities for innovation, especially in operational automation, but before getting started, there are a few things worth considering.

1. Its very different from Integrated Hardware Solutions.
   Traditional switches provide a tightly coupled environment visible through a controlled user interface that is largely descended from the Cisco CLI. SoNiC is Debian with components, its operation is more transparent, but that is good and bad. Network and Linux engineers both can find the platform challenging to understand.
2. Features are a function of the ASIC used, not the Switch vendor.
   The forwarding features provided by SoNiC are dependent on the Switch ASIC vendor, not the badge on the front of the switch. (perhaps with the exception of Mellanox who does both). Understanding each switches forwarding and packet controls requires investigating the switch ASIC vendor, such as Broadcom. This information can be hard to track down and difficult to understand.
3. Compatibility requires Switch Vendor development.
   A supported ASIC is not enough, there are other components in the switch so the switch vendor has work to do. Each switch has a control board, either ARM or Intel that has the usual computer hardware porting requirements. In front of the ASIC’s are the SERDES that implement the physical interface, these are selected by the Switch Vendor and require code to program them usually via an I2C bus. That doesn’t include the mundane things like power suppliers, fans and environmental monitoring.
4. Switch configuration model is different.
   Network Engineers will find the configuration model to be different from traditional platforms. The software is not suited to be interactively configured, but everyone has to start somewhere. The switch configuration and state is maintained in a REDIS database, loaded from a JSON file at start time. A container process called SyncD ensures that the configuration from REDIS is applied to components. However a Network Engineer looking at a configuration may be confused by the lack of parameters. SoNiC is made up on lots of components, the component configuration is abstracted in the configuration database. The configuration is (mostly) defined by and verified using yang models. The database parameters are passed through Jinja templates to create the specific component configuration. For example FRR is used for routing and while the FRR configuration can be viewed and changed in vtysh, it cannot be saved for persistence between reboots. To make things more challenging, the SoNiC CLI does not provide dynamic configuration for all configuration elements and updating the startup configuration JSON requires a reload of the configuration.
5. Packet forwarding is robust, Management tools are a work in progress.
   There are lots of ways to undertake management providing flexibility in adding SoNiC switches to management and automation systems. However each different mechanism has its own unique benefits and challenges. There are direct mechanisms that update JSON (or Minigraph), and Ansible examples. Configuration can be sent directly to the REDIS database however this bypasses the yang model verification. There are additional management abstractions that are deployed in containers. Management Framework provides an OpenAPI configuration with the familiar swagger UI. Telemetry is a newer configuration interface that is still a work in progress using gNMI/gRPC, requiring a golang client. Whether your developing or purchasing platform automation, the mechanism used is a key foundation decision.

Should these things dissuade your investigation into SoNiC, No…..

SoNiC represents the best opportunity for innovation in networking. While there are aspects of SoNiC that will be new to both Linux and Network engineers, there is a lot that’s already familiar. Today there are Switch Vendor, Independent and the opensource version of SoNiC. Supporting upstream Opensource SoNiC requires a specialist team but its achievable, alternatively figuring out the best supported Opensource option requires skill with the platform.

There is a reason there are so many different ways to manage SoNiC. Integrating switches into your operational automation can realize the most immediate benefit.

Its still early days for SoNiC, we are at the start of a significant change in how we source, deploy and manage switches.

If you looking for help on your SoNiC journey, I’m available to help. I am not affiliated with any vendor and can help you evaluate if the time is right and build a strategy to leverage the benefits of Open Networking Hardware and Software. I can be reached at adam@dunstanassoc.com