SONiC network operating system and switch disaggregation

Executive summary

Microsoft developed SONiC for Azure and released it through the Open Compute Project in 2016, creating a shared Linux, container and database architecture for switches from several hardware suppliers.
The Switch Abstraction Interface gives SONiC a common vocabulary for programming different ASICs, but platform capabilities, scale, error behaviour and support still depend on vendor implementations and proprietary SDKs.
Linux Foundation governance broadened participation without removing Microsoft’s influence. Technical authority, project funding, SAI development and production support remain divided among several institutions and commercial participants.
SONiC is expanding into chassis systems, enterprise switching and AI fabrics before uniform conformance and security ownership are fully mature. Its credibility depends on measurable behaviour, not the breadth of its support lists.

A route reaches silicon through a chain of hand-offs

A Border Gateway Protocol route in SONiC does not move directly from a routing process into a switch’s forwarding table. FRRouting receives the update, applies policy and selects the route. Zebra passes forwarding state through the Forwarding Plane Manager interface, fpmsyncd writes application intent into APPL_DB, and the Switch State Service resolves the required neighbours, next hops and interfaces. The request is then serialised through ASIC_DB, consumed by syncd, translated by a vendor’s Switch Abstraction Interface implementation and proprietary software development kit, and finally programmed into the ASIC.

That chain explains both SONiC’s importance and its difficulty. Each boundary lets one part of the system develop without direct knowledge of every other component. Routing software can operate against a common application model, while hardware vendors translate standard switch objects into the instructions required by their silicon. The same separation also creates more places where desired state, reported state and actual forwarding behaviour can diverge.

Traditional network switches generally arrived as vertically integrated products. The supplier combined hardware, operating system, feature roadmap and support relationship, giving the buyer one party to contact when the system failed. The arrangement simplified accountability but tied software choice, automation interfaces and hardware procurement to the same vendor. Large cloud operators managing tens of thousands of broadly similar switches had to accept that coupling or build more of the stack themselves.

SONiC took the second route. It uses Linux as the base, divides network functions into software services, exchanges state through Redis-backed databases and places a hardware abstraction beneath the network applications. The project does not remove hardware differences, and it does not provide one global support contract. It creates a common software layer that can survive a change of switch supplier, original design manufacturer or ASIC family, provided someone completes and supports the platform-specific work beneath it.

The economic promise is disaggregation. An operator can make separate choices about hardware, silicon, operating-system distribution, integration and support instead of purchasing them as one product. The operational consequence is divided responsibility. A feature can exist in the community release but remain unavailable or behave differently on a particular platform because the decisive limitation sits in firmware, drivers, vendor SAI code, an SDK or the physical pipeline.

Azure turned a fleet problem into an open platform

Microsoft developed SONiC for Azure before presenting it publicly. Its origin was therefore a production problem rather than an abstract proposal for open networking. Hyperscale operators need to automate large switch fleets, change software faster than conventional product cycles may allow and purchase hardware from several suppliers without maintaining a completely different operational model for each one.

Microsoft announced its contribution of SONiC to the Open Compute Project on 9 March 2016. The name stands for Software for Open Networking in the Cloud. Microsoft described it as a collection of software-networking components for switches and paired it with the Switch Abstraction Interface, or SAI. That pairing was essential because a portable upper stack would have offered limited value if every routing, orchestration and management application still needed direct knowledge of each silicon vendor’s interface.

SAI supplied a common programming vocabulary for objects including ports, VLANs, routes, next hops, neighbours, access-control entries, queues, buffers, tunnels and counters. An ASIC or platform vendor could implement those objects against its own SDK and forwarding pipeline. SONiC applications could then request a standard object instead of embedding proprietary hardware calls throughout the common code.

Open Compute Project participation connected the software to data-centre operators, original design manufacturers, switch vendors and silicon companies already working on open hardware and hardware-software co-design. Microsoft brought a real operating environment, while the wider group supplied the hardware diversity required to test the project’s promise. Neither factor made portability complete. Every platform still needed boot integration, drivers, thermal management, optics handling, a SAI implementation, SDK support and sustained testing.

The less visible work became the foundation of the ecosystem. Common routing, orchestration and management code could be shared, while the companies closest to the hardware maintained the platform-specific layers. Microsoft continued to supply engineering and requirements drawn from Azure, but other cloud operators, vendors and integrators acquired a route into the project that did not depend solely on one company’s internal roadmap.

That history makes Microsoft’s present role easier to understand. The company created SONiC and accumulated years of operating knowledge before neutral governance was established. Moving the project did not erase that advantage. It created a framework in which other companies could invest, govern and contribute without pretending that the originator’s production experience had become interchangeable overnight.

Linux and Redis made the switch modular—and stateful

SONiC is usually described as a Linux-based network operating system, but Linux alone does not explain its architecture. The host system supplies the kernel, device access and base services. Major network functions run in separate containers, while Redis-backed databases provide the shared state and messaging interfaces through which those services coordinate. The Switch State Service converts application intent into SAI operations, and a hardware-facing process connects those operations to the vendor implementation.

The container structure has historically separated functions including routing, Link Layer Discovery Protocol, Simple Network Management Protocol, link aggregation, platform monitoring, databases, SWSS and ASIC synchronisation. The separation improves packaging and organisational ownership, but it should not be mistaken for a strong security boundary in every case. Networking services may share host resources and require elevated privileges to interact with the kernel and hardware. Their value lies chiefly in allowing components to be developed, restarted and upgraded without compiling the complete switch into one opaque process.

Redis provides the common language. CONFIG_DB contains intended configuration. APPL_DB carries application-level forwarding and service intent towards the orchestration layer. ASIC_DB represents serialised SAI objects for the hardware-facing process, while STATE_DB records runtime readiness and dependencies. COUNTERS_DB stores interface and hardware statistics used by operational tools and telemetry.

Configuration may enter through files, command-line tools, gNMI, REST or other management software. Manager processes translate that input into application operations, and SWSS consumes the resulting state. orchagent resolves dependencies and creates SAI requests, sairedis serialises them into ASIC_DB, and syncd calls the vendor SAI library and SDK. Components written in different languages and maintained by different teams can therefore coordinate through defined state rather than a dense web of private calls.

The result is a distributed state machine. A database key can become stale, one writer can race another, and an application can accept intended state before the hardware rejects it. Counters can place pressure on the database path, while restarts require several containers to reconstruct a consistent view of what the switch should be doing. Redis is not a passive implementation detail. Its schemas, persistence and failure behaviour influence the reliability of the entire system.

Modularity makes these transitions more visible. Operators can inspect where a request has reached and identify which service owns the next step. Visibility does not ensure correctness, however. A route selected in FRRouting, written into APPL_DB and represented in ASIC_DB may still be absent from the forwarding hardware. The system needs reconciliation, diagnostics and traffic evidence capable of distinguishing administrative acceptance from actual packet delivery.

SAI moved the proprietary boundary without removing it

SAI is the principal reason SONiC can maintain a broadly common upper architecture across several ASIC families. orchagent can request a route, port, next hop, access-control entry, queue, tunnel or counter without containing one vendor’s SDK calls. That reduces coupling and gives network applications a stable object model even when the underlying switch supplier changes.

The interface cannot make physically different ASICs equivalent. Silicon varies in table capacity, pipeline design, buffer architecture, supported object combinations, counter semantics, telemetry functions, update atomicity, tunnel processing and restart behaviour. A vendor must map SAI objects onto those resources, often through proprietary code and an SDK that community maintainers cannot inspect.

Two platforms can therefore advertise the same SAI version while offering materially different behaviour. One may support a larger EVPN table, a more complex access-control policy or a warmer restart than another. A feature may require a silicon capability or SAI extension absent from an earlier chip. The common interface reduces how much upper software must change, but it does not certify scale or output.

The governance boundary reinforces the technical one. SONiC moved to the Linux Foundation in April 2022, while SAI remained under the Open Compute Project. The two communities coordinate, but they do not share identical decision structures. A new requirement in telemetry, AI networking or scale-up Ethernet may need simultaneous changes to SONiC applications, SAI definitions, vendor implementations, SDKs and silicon.

Troubleshooting follows the same chain. A valid request may fail in common orchestration code, a vendor adapter, an SDK or the hardware itself. Community maintainers may see the SAI error without access to the proprietary layer that produced it, while a hardware vendor may support only a specific image and SDK combination. A commercial distribution can accept more of this integration burden, but community SONiC does not create one universal escalation path.

SONiC has therefore moved vendor dependence towards a narrower and more explicit hardware-facing boundary. That is a substantial architectural change. It has not removed the dependency, and in difficult failures the final answer may still come from the company that controls the proprietary implementation closest to the ASIC.

State reconciliation is the price of modularity

An application can accept a configuration, write it into the expected database and report completion before the hardware-facing layer discovers that the ASIC cannot create the requested object. When the failure does not return through the chain with enough context, intended state, application state and real forwarding state no longer match. A modular system makes that divergence easier to locate but also gives it more places to occur.

Some historical SONiC designs treated SAI create or set failures as fatal. Stopping a process may be safer than continuing with unknown hardware state, but it can leave the switch difficult to recover. Later error-handling work introduced designs including ERROR_DB and application feedback for selected objects such as routes and neighbours. The aim is to give an asynchronous request a durable result that the originating application and management client can interpret.

A configuration change may involve several dependent operations. The system might create a next-hop group, add members, update a route and remove old state. Some steps can succeed before a later call fails, and the hardware’s available resources may change between validation and execution. A literal rollback may be impossible or unsafe, forcing the system to correct forwards towards a consistent state.

Warm restart brings the same problem into upgrades and process recovery. The objective is to restart software without discarding forwarding state and interrupting all traffic. The new process must reconcile what its predecessor intended, what Redis contains and what the ASIC continues to do. Schema changes, stale keys or partly restored dependencies can turn persistence into another source of uncertainty.

Operators consequently need more than a successful command response. CONFIG_DB can confirm that a request was accepted, APPL_DB that it was translated, and ASIC_DB that a SAI object was requested. None proves that packets are following the intended path. Hardware counters, external traffic tests and state reconciliation remain part of normal assurance.

The architecture exposes a fact that integrated systems often hide: network configuration is not one atomic write. It is a sequence of state transitions across components with different timing and failure behaviour. SONiC’s reliability depends on how well those components recover after delay, rejection, restart and partial completion.

Chassis systems multiply both scale and failure

SONiC’s early public image was closely associated with fixed-form-factor data-centre switches containing one principal forwarding ASIC. The project has since expanded into high-density switches, modular chassis and distributed virtual-output-queue systems with several forwarding ASICs, fabric devices, line cards and management components.

A multi-ASIC system may run separate instances of Redis, SWSS, syncd, routing, link discovery and link aggregation for each forwarding device. Each ASIC can have its own SAI and SDK instance. The software must determine which interfaces, neighbours and routes belong to each namespace, how internal links are represented and how state moves between devices.

The larger system changes the failure domain. A route may enter one ASIC and leave through another, while a front-panel link depends on an internal fabric path. Counters gathered in separate namespaces must be presented as part of one logical switch. One line card may restart while other cards and the control plane continue operating, forcing the software to coordinate versions, object ownership and fabric reachability across independently stateful components.

Distributed VOQ architectures extend this coordination across a chassis or several switch instances. Forwarding and queueing decisions may depend on shared knowledge of remote ports and fabric state. Line-card replacement, control-plane redundancy and partial fabric failure must be handled without assuming every component is available at the same time.

The SONiC 202605 release included limited multi-ASIC warm reboot as an Alpha feature for a restricted topology. That label is as important as the feature’s presence. It confirms active implementation work while making clear that resilient restart across complex multi-ASIC systems was not yet a universally qualified capability.

Chassis support expands SONiC’s relevance to telecom networks, high-density clouds and AI infrastructure. It also brings the project into systems where integrated vendors have accumulated years of platform-specific recovery logic. The open architecture can compete, but test coverage, upgrade sequencing and support obligations grow faster than the ASIC count alone.

Management decides whether openness can be operated

A common switch operating system is useful only when operators can configure, observe and upgrade it across a fleet. SONiC supports command-line tools, static configuration, SNMP and work involving gNMI, YANG, REST, OpenAPI, Translib and validation frameworks. The available functions still depend on the release, data model, distribution and platform.

Model-driven management is intended to translate an external request into the Redis-based configuration system. YANG models define valid structures, while CVL and related components can reject malformed input. Translib and service components map API operations into SONiC tables, allowing controllers to work through a supported interface rather than manipulate internal databases directly.

Schema validation cannot prove that a requested service is authorised, compatible with another change or supportable by the ASIC’s remaining resources. A documented design also described compare-and-swap operations without general locking or rollback. Application developers must therefore define ownership, concurrency and compensation instead of assuming that the management layer supplies a universal transaction.

OpenConfig and gNMI show the difference between including a component and completing an operational feature. SONiC 202605 included sonic-gnmi 0.1, while OpenConfig YANG dial-out telemetry remained Alpha. A useful support statement must identify the model, path, read or write operation, telemetry mode, release and vendor distribution. The broad claim that a switch supports OpenConfig conveys too little.

Legacy interfaces remain necessary. SNMP links switches to established monitoring systems, LLDP supplies neighbour information, and platform services expose fans, temperature, power and optics. BMC and Redfish work addresses out-of-band lifecycle functions, but several related workflows in the 202605 release also retained Alpha status.

Enterprise switching raises another set of management expectations. SONiC was designed for hyperscale environments whose operators can build images, run qualification laboratories and maintain direct hardware relationships. Campus and access networks require functions such as Power over Ethernet, spanning tree, 802.1X admission control and predictable endpoint management, often for teams without cloud-scale engineering capacity.

The PENS working group, covering PoE and enterprise-networking services, is one attempt to close that gap. Other groups address management, platform operating systems, BMC integration, virtual data planes and documentation. Their existence shows active work, not uniform maturity. Enterprise adoption will depend on moving functions from design and implementation through release inclusion, hardware qualification and supported commercial delivery.

Commercial distributions become particularly important at this boundary. They can provide a tested management surface, upgrade policy, hardware matrix and support process around the upstream components. Community SONiC supplies the common base; the operator still needs one party to own the lifecycle of the image actually running on the switch.

The Foundation name covers a project and a directed fund

The name “SONiC Foundation” can suggest a separately incorporated organisation with its own statutory board, employees and accounts. The available governance record supports a more layered description. The SONiC Foundation is the Linux Foundation-hosted technical project and community, while no separately incorporated SONiC Foundation company or independent nonprofit legal entity was identified in the supplied evidence.

A related structure, the SONiC Fund, is a Linux Foundation Directed Fund. It raises and spends money in support of the technical project. Its Governing Board oversees membership, budgets, outreach, policies and potential conformance programmes. The Technical Steering Committee deals with technical direction, and although it is represented within the wider structure, technical and financial authority remain distinct.

This division prevents membership from becoming a proxy for deployment or technical command. A company can join the Directed Fund without running SONiC in production. A Governing Board seat does not decide every design discussion, and a contributor can influence the software without purchasing Premier membership. The Linux Foundation administers project funds and marks, while code rights remain governed by the relevant licences and contributor copyrights.

SAI adds a further institutional boundary because it remains an Open Compute Project initiative. The SONiC project develops the common operating software, the Directed Fund finances and promotes that work, OCP hosts SAI and related hardware activity, and vendors or operators integrate the resulting components with switches and commercial support. Dell Enterprise SONiC and other distributions sit downstream from the community project rather than turning the Foundation into a conventional software vendor.

The arrangement identifies where decisions and liability reside. A working group and the TSC may shape a feature, the Directed Fund charter governs membership fees, and OCP participants develop a SAI object or version. A production fault may still require a proprietary SDK team or the supplier that qualified the final image. Treating every layer as one Foundation would conceal the boundaries that operators must manage.

Neutral governance has not erased Microsoft’s influence

The Linux Foundation announced SONiC’s transition on 14 April 2022. By then, the project had outgrown the appearance of one cloud company’s internal stack. A neutral framework offered shared membership, funding, elections, branding and technical participation to companies that might otherwise hesitate to depend on Microsoft-hosted governance.

The announcement said SONiC was already running on millions of ports and more than 100 switch models, with over 50 partners. These were project and creator claims rather than an independent census. They nevertheless show that the move was presented as the institutionalisation of a deployed platform, not the incubation of a new experiment.

The Directed Fund charter amended on 5 May 2026 allows Premier members to appoint Governing Board representatives. General members elect representatives as a class according to the size of that membership, while Associate members do not receive Board seats. The Board is normally capped at 19 voting representatives unless increased, quorum is 50 per cent, and ordinary decisions require a simple majority where quorum exists, although consensus is preferred.

The annual Directed Fund fee for a Premier member is US$100,000, separate from the required Linux Foundation corporate membership. General-member fees range from US$1,000 for organisations with up to 499 employees to US$20,000 for organisations with at least 5,000 employees. Approved Associate members participate without a Fund fee. The Linux Foundation applies a general and administrative charge of 9 per cent to the first US$1 million in annual gross receipts and 6 per cent above that level.

These figures explain the funding mechanism but do not disclose the project’s actual budget. No public annual Fund receipts, expenditure, reserves or programme-level allocation were identified. Governing Board meetings are private by default unless the Board decides otherwise, making technical repositories and working groups more visible than the financial choices supporting testing, events, outreach or infrastructure.

Cash is only one part of the contribution model. Microsoft, cloud operators, silicon companies, switch vendors and integrators provide engineering, platform ports, SAI implementations, laboratories, continuous-integration capacity, documentation and release work. The value of those contributions is not published as one financial total, and the project remains exposed when a corporate team changes priorities.

Microsoft occupies the most visible concentration of current leadership. At the research cutoff, Dave Maltz chaired the Governing Board, Xin Liu chaired the Outreach Committee and Guohan Lu chaired the Technical Steering Committee. Microsoft was also the project’s creator, a Premier member, an active contributor and a major production operator.

The wider governance is genuinely multi-company. Governing Board representation has included Alibaba Cloud, Arista, Broadcom, Celestica, Cisco, Dell, Google, Marvell, Nokia, NVIDIA, PLVision, Upscale AI, Nexthop AI and others. The 2026 TSC election produced one chair and eight voting members associated with Microsoft, Google, Broadcom, NVIDIA, Alibaba Cloud, Cisco, Dell, Marvell and an independent affiliation.

Formal voting does not capture all technical authority. The project describes a meritocratic model and acknowledges an element of “benevolent dictatorship” at component or project level for resolving conflict. Maintainers and engineers with deep operational knowledge can influence outcomes because other participants depend on their reviews, even when financial governance remains separate.

Microsoft’s advantage combines leadership positions with operating evidence from Azure. Failures, upgrades and scale limits generate knowledge that public design documents rarely capture. The test of neutral governance is therefore whether other organisations can own difficult subsystems, challenge design choices and sustain releases if Microsoft’s priorities change. Board diversity provides a framework; contribution concentration and maintainer ownership would provide stronger evidence.

Releases define a baseline, not a certified product

SONiC 202605 shows how much software a modern network operating system integrates. The release used Debian 13 Trixie, a 6.12.41 SONiC kernel, SAI 1.18.1, FRR 10.5.4, Redis 8.0.2, Docker 28.2.1 and Python 3.13.5. It also brought together link discovery, aggregation, SNMP, DHCP, routing advertisements, telemetry and platform packages whose security and lifecycle do not move on one schedule.

The dependency list establishes a branch-level baseline. It does not mean that every switch runs identical binaries. Platform images can contain vendor kernel modules, SAI libraries, SDKs, firmware, drivers and configuration, while commercial distributions may carry patches that are absent from the community branch.

Quality labels are therefore essential. The 202605 release classified OpenConfig YANG dial-out telemetry, limited multi-ASIC warm reboot, BMC Redfish workflows, self-encrypting-drive password operations, telemetry VRF binding and an event or alarm framework as Alpha. Users can evaluate those implementations, but release inclusion is not a promise of stable behaviour across all listed platforms.

Testing must cover combinations of ASIC, switch, topology, feature, branch and upgrade path. Public sonic-mgmt conditions include platform-specific skips and expected failures. A skip can indicate an unsupported function, a test limitation, a known issue or an irrelevant case, so it should not automatically be treated as a product defect. The wider pattern still shows why the phrase “supports SONiC” is too broad for procurement.

A meaningful platform statement identifies the hardware, ASIC, image provider, SONiC release, SAI implementation, SDK, tested features and support owner. Warm reboot on one fixed switch says little about a distributed chassis. An access-control scale on one ASIC cannot be transferred to another, and a gNMI path in the community image may differ from the interface offered by a commercial distribution.

The community can publish a common release and testing framework, but production accountability belongs to the operator and the parties that qualified the final image. The Directed Fund charter allows conformance programmes, yet no comprehensive independent matrix showing comparable pass-and-fail results across current platforms was identified. Until such evidence exists, a release is an integration contract around common code, not a universal certification of the systems built from it.

AI fabrics are the sharpest test of the common layer

Large GPU clusters are changing the demands placed on data-centre networks. Distributed training can generate long-lived synchronised flows, low traffic entropy, microbursts and performance that is limited by the slowest participant. Operators need high bandwidth, rapid failure convergence, dense neighbour and session scale, precise congestion evidence and features that may depend on new switch silicon.

A July 2026 SONiC Foundation article by Microsoft’s Guohan Lu and Broadcom’s Mehak Mahajan described Microsoft’s Fairwater architecture and four capabilities said to be available by the 2025.11 release: higher BGP scale, source-selected traffic distribution based on SRv6, packet trimming and high-frequency streaming telemetry. The same article described a multi-plane, multi-rail design intended to support as many as 512,000 GPUs. These were project and practitioner claims, not independently audited evidence that the full number was operating simultaneously.

The BGP work was described as supporting 512 sessions per switch, about 1,000 routes and 512 next hops in the relevant design. FRR 10 and roughly 20 targeted patches were said to produce data-plane convergence below 100 milliseconds. The article did not provide a complete topology, percentile distribution, hardware specification or independently reproducible method, so the figure belongs to the reported architecture rather than to SONiC as a universal performance guarantee.

SRv6 and uSID address the limited entropy created by a small number of very large flows. Endpoint-selected paths can distribute traffic more deliberately than conventional hashing, but the mechanism requires compatible endpoints or NICs, suitable ASIC parsing, table capacity, routing support and failure recovery. The operating-system feature works only as part of a coordinated stack.

Packet trimming preserves a short header from a dropped packet and forwards it so that the destination can detect loss more quickly. The Foundation article described a hardware-specific case in which trimmed headers from as many as 18 ingress ports could drain through one egress on current 512-port hardware. The result depends on the ASIC and traffic pattern and does not show that every SONiC platform or endpoint supports the mechanism.

High-frequency telemetry is intended to capture events missed by slower polling. The described path uses ASIC IPFIX counter export, Counter SyncD, COUNTERS_DB and either on-switch analysis or OpenTelemetry export to systems such as Prometheus or InfluxDB. That design places Redis and telemetry processing inside the AI fabric’s feedback loop, increasing both their operational value and their performance burden.

Membership has followed the same direction. Upscale AI became a Premier member in February 2026. Supranett joined at the Premier level on 28 July, while Exaware, TeraHop and Infrawaves became General members. Nexthop AI and other AI-networking companies also hold governance or working-group roles. Membership shows investment and intent, not deployment, but it identifies the problems companies expect the common platform to solve.

Scale-up Ethernet pushes SONiC closer to accelerator systems that have historically used specialised interconnects. The Scale-Up Ethernet working group is intended to translate emerging requirements, including work aligned with OCP E-SUN, into implementations covering link-level retry, credit-based flow control, adaptive flow hashing, scale-up packet headers and larger endpoint fabrics.

The opportunity is significant. A mature implementation could allow one open network-operating-system environment to serve large scale-out fabrics and parts of an emerging scale-up Ethernet market. Operators might reuse management, telemetry and platform practices across more of the AI network.

The work had not reached a finished universal standard or broad deployment at the research cutoff. Requirements were still evolving, vendors could expose essential functions through extensions, and changes had to cross SONiC, SAI, endpoint software, NICs, firmware and silicon. As SONiC moves closer to specialised accelerator behaviour, precise hardware semantics become more important. The common layer may expand while the proprietary boundary beneath it grows more consequential.

Security became formal after the platform was already in production

A SONiC image combines Debian, the Linux kernel, a container runtime, Redis, FRRouting, management services, LLDP, SNMP, DHCP components, Python packages, platform drivers, vendor SAI libraries, proprietary SDKs, firmware and build infrastructure. A vulnerability in any of those layers can affect the switch or its management plane, while responsibility for correction may be divided among several projects and suppliers.

A public Security Working Group was approved in June 2026. Its scope included software bills of materials, Vulnerability Exploitability eXchange information, dependency hygiene, static and dynamic analysis, fuzzing, penetration testing, supply-chain security, hardening and secure or measured boot. Brad House of Nexthop AI was identified as chair and Qi Luo of Microsoft as co-chair.

The formation document acknowledged that substantial security work had previously lacked sufficiently clear ownership. Security was not absent: upstream projects, maintainers and vendors had handled vulnerabilities, and a reporting process existed. The admission was that responsibility across the integrated system had not been organised into a visible public workstream commensurate with the platform’s production use.

A working group does not complete that task. A mature programme needs current SBOMs, provenance records, vulnerability triage, signed or reproducible builds, patch policies, private disclosure handling, backports and platform-specific advisories. Proprietary SAI libraries, SDKs and firmware complicate the upstream view because the community may neither inspect their source nor control their release schedules.

Management services deserve particular scrutiny. gNMI, REST, SSH and SNMP expose privileged control or information, requiring certificate management, role design, audit, secrets handling and network isolation. Containers improve packaging but do not automatically create strong security boundaries when they share host resources and require elevated capabilities. A compromise in the orchestration or database path can affect many forwarding objects.

Commercial vendors issue their own advisories because their products contain different combinations and support policies. A vulnerability in Dell Enterprise SONiC should not automatically be generalised to every community image, while an operator cannot assume that the upstream project page covers every proprietary component in its switch.

The Security Working Group has become one of the clearest tests of project maturity. SONiC has shown that open collaboration can integrate routing, databases and hardware abstraction. It must now show that the same institutional model can assign ownership across a supply chain whose most sensitive layers are not all open.

Open source shifts support costs rather than removing them

Community SONiC supplies source code, architecture, releases, working groups and a shared testing framework. It does not provide a universal production service-level agreement. An operator using the community project must still assign responsibility for hardware qualification, image assembly, upgrades, security backports, incident response and the relationship with the ASIC or platform supplier.

Hyperscalers may accept that burden because control of the stack is the reason they pursued disaggregation. They can maintain Linux, routing, release-engineering and hardware teams, run qualification laboratories and negotiate directly with silicon suppliers. Their operating model converts software independence into a substantial internal engineering commitment.

Many enterprises and service providers need a supplier to absorb more of the integration risk. Dell offers Enterprise SONiC with qualified hardware and commercial support. Nokia provides community SONiC images and support on selected platforms, while other switch vendors, original design manufacturers and integrators package their own combinations. These offerings can establish a clearer escalation path, but they may diverge in patches, management functions, hardware coverage and release timing.

The commercial layer is where lifecycle work and liability are sold. Cloud operators gain procurement flexibility; switch and silicon vendors sell systems; distributors sell subscriptions and support; integrators sell engineering; and customers may reduce dependence on one vertically integrated supplier. The Directed Fund itself has no equity shareholders, corporate valuation or published standalone profit.

Participants cooperate around the shared layer while competing above and below it. Arista, Cisco, Dell, Nokia and NVIDIA can contribute to the same project while selling different products. Cloud operators can support common interfaces while negotiating aggressively with hardware suppliers, and ASIC companies benefit when SONiC makes their silicon easier to integrate while retaining differentiation in features and performance.

The common layer reduces duplicated work only where participants accept common behaviour. Private SAI implementations, downstream patches and vendor extensions can weaken portability even when products share the SONiC name. Companies have an incentive to contribute enough to sustain the ecosystem while preserving enough difference to sell their own offering.

Membership fees make financial participation visible, but engineering is likely the larger currency. A US$100,000 Premier fee is significant to the Fund and small beside the cost of maintaining a specialist team or hardware laboratory. Organisations that supply years of implementation and testing can shape outcomes through operating reality even when the charter formally separates payment from technical acceptance.

The lack of a public Fund budget limits analysis of how cash priorities are chosen. More financial transparency would help operators compare stated priorities with expenditure on security, testing, documentation, continuous integration and conformance. The creation of the Security Working Group shows that a critical area can remain insufficiently owned even when the ecosystem contains large and well-resourced members.

Buyers should treat “SONiC-based” as the beginning of due diligence rather than its conclusion. They need the branch, SAI version, SDK, firmware, image owner, qualified features, security policy and support path. They also need to know whether the image can be reproduced and what happens when community, vendor and hardware release schedules diverge.

Disaggregation creates choice only when those boundaries remain visible. An operator can otherwise replace one vendor lock-in with dependence on a custom image, one integrator or an SDK build that cannot be maintained elsewhere. The open architecture makes alternatives possible; support contracts and internal engineering determine whether they remain usable.

Deployment is substantial, but comparability remains weak

The Linux Foundation’s 2022 transition announcement said SONiC was running on millions of ports and more than 100 switch models. In April 2024, the Foundation reported 4,250 contributors from more than 520 organisations and annual community growth of 20 per cent. A governance biography stated that Alibaba operated close to 100,000 SONiC-based switches, gateways and routers.

Each figure indicates scale, but none is an independent audited census. Contributor totals can include historical participants rather than active maintainers, a supported model may have little production volume, and Foundation membership does not prove deployment. Public claims describe different units and cannot be combined into one reliable market share.

Named cases provide firmer evidence of use. Microsoft developed and operates SONiC in Azure. Alibaba, eBay and EPFL supported the Linux Foundation transition and described their use. Orange reported an initial production deployment of about 90 switches in 2024 and an intention to expand, while Foundation materials later highlighted SAKURAONE, Tokyo-1, Rakuten and Indian payments deployments. Dell and Nokia offer supported products tied to selected hardware.

The evidence is more than sufficient to reject the description of SONiC as an experimental laboratory project. It has a production origin, active repositories, several silicon and hardware partners, commercial distributions and named operator deployments. What remains unavailable is a consistent measure of active systems, supported feature sets and comparable behaviour across platforms.

That limitation becomes more important as SONiC expands into enterprise networks and AI fabrics. Aggregate port numbers offer category confidence, while platform-level evidence decides whether a particular deployment is supportable. Operators need the release, ASIC, image, feature matrix, upgrade record, incident history and accountable supplier.

SONiC sits between custom hyperscale software and vertically integrated commercial network products. Arista EOS, Cisco NX-OS, Junos and Nokia SR Linux offer mature systems with one supported product relationship. NVIDIA Cumulus Linux provides another commercial Linux-based approach. Dell Enterprise SONiC and supported Nokia offerings commercialise the SONiC base, while DENT, FBOSS, Open Network Linux, Stratum and Linux switchdev represent adjacent open or operator-developed architectures.

SONiC’s advantage is the scale of the shared ecosystem around one Linux, container, Redis, SWSS and SAI model. Operators can inspect and modify common code, select from several hardware paths and reuse parts of their automation across suppliers. Its disadvantage is the integration matrix created by that freedom. Performance and support depend on how successfully the layers have been reassembled.

AI networking raises the stakes because buyers are purchasing large switch volumes while demanding new functions quickly. A common operating system can reduce duplicated integration across system and silicon vendors. The same urgency can encourage extensions that solve one deployment while weakening portability. SONiC’s market position will depend on whether its interfaces keep pace without becoming nominal abstractions over incompatible implementations.

The boundary is visible; accountability still has to be proved

SONiC changed network switching by turning a cloud operator’s internal architecture into a shared software platform. Linux, containers and Redis created a common operating plane. SWSS separated application intent from hardware operations, and SAI gave several ASIC families a common object model. Linux Foundation governance provided a more neutral structure through which competing companies could fund and develop the software.

The project has not made switches interchangeable. It does not certify every listed platform, remove proprietary SDKs or provide one support experience. A community release can contain Alpha functions, while a shared SAI version can conceal different capacity, error behaviour and restart characteristics. Security coordination cannot control components the upstream project neither owns nor sees.

Those limits reveal the project’s real contribution. Before disaggregation, the hardware-software boundary sat largely inside one supplier. SONiC made more of it explicit and contestable, allowing operators to identify which functions are common, which remain platform-specific and which party has accepted responsibility for the final system.

The next phase will test whether that boundary can remain coherent as the platform expands. AI scale-out fabrics demand rapid convergence and high-frequency telemetry. Scale-up Ethernet moves closer to accelerator systems, multi-ASIC chassis increase state complexity, enterprise work broadens the user base, and security governance must span a large mixed-source supply chain.

SONiC has separated a large and valuable part of the switch operating system from one supplier’s hardware stack. It has not separated forwarding from silicon, and no software architecture could do so. Interoperability still depends on SAI implementations, SDKs, drivers, firmware, optics, qualification and support.

The observable test is therefore not how many products carry the SONiC name. It is whether different platforms can demonstrate comparable behaviour, whether security and maintenance ownership survive corporate changes, and whether an operator can move between supported systems without rebuilding the operational model around another undocumented dependency.

SONiC and the unfinished separation of switch software from hardware

Why it matters