What is SONiC?

Software for Open Networking in the Cloud (SONiC) is the open networking solution used in Microsoft's Azure Cloud. The System is used in the lower layer of their Datacenter fabric (TOR and Aggregation).

This environment provides a solution to a very specific use case scenario, where only a very limited set of functionality is needed, but programability, integration in existing IT management systems and reliability are key.

With this in mind, Microsoft created a software stack on top of ONIE + SAI, using a cloud like approach, and in this environment well known software components.

The following architecture diagram shows the main components and their interaction:

So all the forwarding / control applications run in Docker containers. This very modular approach makes replacing single applications very easy, as just the docker container needs to be replaced. This also does not require any updates or interactions with the core OS below, and by that also does not touch any component that other containers might depend on. Docker Swarm then allows to scale Docker operations very easily over the number of devices expected in Cloud environments.

The applications used in SONiC are mostly based on standard, open source Linux projects like Quagga, Zebra or similar. If we look at a running SONiC device, we can see the relevant docker containers relating to this diagram running:

• IMAGE NAMES
• docker-orchagent-mlnx swss
• docker-syncd-mlnx syncd
• docker-fpm bgp
• docker-snmp-sv2 snmp
• docker-platform-monitor pmon
• docker-lldp-sv2 lldp
• docker-database database

Additionally, the backend database is Redis, a standard in memory database in Linux / Cloud scale environments.

The application containers read and write their data into app specific parts of the database, from where the Orchestration agent grabs it and puts the data needed for configuring the ASIC forwarding into the SAI part of the database, translating the information as needed.

From the SAI database, a syncer daemon then pushes the information through the SAI API into the chipset, and forwarding now happens at line rate.

Configuration of the whole SONiC stack is done through one file on the host OS, named minigraph.xml. This file holds all the host configuration for ports, the docker container config, and the app specific configurations. The docker containers then map the parts relevant to them into their own file system, and configure themselves accordingly. This one file approach is ideal to be used for bulk configuration of devices using puppet or ansible.

It is important to remember that this system is not meant to replace your traditional core router, and would in the current implementation not be able to do so. It is a very slimmed down implementation meant to be run internally, in the lower layers of a cloud fabric. It is a very use case specific solution, in it's current state not meant to replace network devices outside the DC. But it is a very important blue print that might be applied to other networking scenarios, where a specific, limited functionality could be achieved easier and more cost effective than with standard networking hardware.

You can find more information on the Azure networking blog, or the SONiC github page.

You can find our hands on examples here: