SONiC Overview

Architecture, Configuration, and Automation

Published

July 1, 2026

Modified

July 3, 2026

Abstract

SONiC is an open-source, container-based network operating system that decouples switching software from proprietary hardware via the Switch Abstraction Interface (SAI). This post covers its Redis-driven microservices architecture, configuration workflows, and automation options including Ansible, RESTCONF, and gNMI. It compares Community and Enterprise distributions, examines project health and production deployments, and details upgrade strategies — from zero-downtime warm reboots to per-container patches and firmware updates.

Keywords

Sonic, Network

Overview

SONiC1 (Software for Open Networking in the Cloud) is a free, open-source network operating system based on Linux2. Microsoft and the Open Compute Project developed it to run Azure’s global data center networks and open-sourced it in 2016. The Linux Foundation assumed stewardship in 2022 for neutral governance.

SONiC decouples network software from proprietary hardware through the Switch Abstraction Interface (SAI)3, a standardized API for programming switching ASICs. A single software stack runs across 100+ switch platforms from multiple vendors, including Broadcom, Intel, and NVIDIA silicon.

Its container-based architecture replaces monolithic switch software with isolated Docker containers per network function. Each container communicates via a central Redis key-value store, enabling fine-grained failure recovery and in-service upgrades without data plane downtime. The FRRouting suite provides BGP, OSPF, and IS-IS protocol support.

Modern data center networks carry more east-west traffic—communication between application nodes—than north-south traffic to external networks. This shift demands a network OS that handles massive internal forwarding with predictable latency and full bisection bandwidth. SONiC meets that demand. Cloud providers have hardened it in production; enterprises, fintech firms, and AI/ML clusters now use it too.

Use SONiC for deployments that require vendor neutrality, programmatic control over network behavior, or whitebox hardware to reduce cost. It suits teams willing to manage their own software instead of relying on a single vendor’s support contract. Small networks with a handful of switches and no automation needs are better served by a vendor-supplied OS with integrated support. Once you need multi-vendor hardware, custom protocol behavior, or independent patching and upgrades, SONiC’s open model becomes hard to replace.

SONiC supports any network topology. It implements standard routing protocols — BGP, OSPF, IS-IS — that work in CLOS fabrics, traditional three-tier hierarchies, campus networks, and provider edge deployments. The association between SONiC and CLOS stems from Microsoft’s original use of SONiC in Azure’s spine-and-leaf fabrics, not from any architectural constraint.

Comparison

The decision between SONiC and a traditional vendor NOS comes down to flexibility versus accountability.

Table 1: SONiC versus traditional network operating systems
Attribute SONiC Traditional NOS
License cost Free (Apache 2.0) Bundled in hardware at significant cost
Architecture Containerized microservices Monolithic or semi-modular
Hardware 100+ whitebox platforms, multi-vendor Vendor-locked only
Control On-box FRR (BGP, OSPF, IS-IS) On-box, proprietary implementations
Automation API-first; RESTCONF, gNMI, Redis, Ansible NETCONF/RESTCONF; legacy CLI-heavy
Kubernetes Native CNI integrations Limited; requires vendor-specific plugins
Maturity DC/HPC-strong; campus/WAN gaps 30+ years; comprehensive across all domains
Support Community + commercial distros Dedicated technical assistance center (TAC); guaranteed service-level agreements (SLA)
Upgrade Per-container, warm restart, patching OS-level, vendor-controlled schedule
Best fit Data center fabrics, clusters, Kubernetes Enterprise campus, WAN, branch networks

For HPC and data center workloads, SONiC’s advantages are concrete. Lossless Ethernet tuning for RoCEv2, BGP-based EVPN/VXLAN overlays, and full programmatic control over buffer profiles and QoS maps directly to the needs of GPU clusters and high-performance compute fabrics. Kubernetes networking is built in rather than bolted on — SONiC integrates with Calico, Cilium, and Multus as a standard underlay, letting you manage pod networking alongside bare-metal compute without switching toolchains. At scale, a 48-port 100G leaf on whitebox hardware runs 40–60% cheaper than a branded equivalent when factoring in hardware, OS licenses, and support contracts4.

Traditional NOS retains value where single-vendor accountability matters more than cost or flexibility. If your organization needs dedicated TAC engineers who can troubleshoot the full stack from silicon to software, or if you operate outside the data center — campus Wi-Fi, voice, wide-area routing — platforms like IOS-XE, Junos, and EOS remain the default. For a science institute focused on cluster computing and Kubernetes expansion, those trade-offs favor SONiC.

Distributions

Community SONiC5 is the upstream, open-source project maintained by the Linux Foundation. It runs on white-box and ODM hardware across multiple ASICs — Broadcom, Marvell, Intel, NVIDIA — with no vendor support contract attached. The community releases features frequently, but management tooling, platform testing, and advanced API coverage may have gaps. You are responsible for building, validating, patching, and troubleshooting it yourself.

Enterprise SONiC is a commercial distribution built on top of the community code base. Vendors like Broadcom, Dell, and Asterfusion add hardened, thoroughly validated releases with predictable lifecycle maintenance. They extend feature coverage — complete RESTCONF/gNMI models, multi-ASIC chassis support, advanced BGP/EVPN, and security hardening — and provide integrated management tooling alongside 24/7 technical support with SLAs.

The trade-off is flexibility versus accountability. Community SONiC offers maximum hardware freedom but requires in-house engineering capacity to operate reliably. Enterprise distributions often tie you to specific hardware (e.g., Dell Enterprise SONiC only runs on Dell PowerSwitch) and come at a licensing cost. Think of it as Fedora versus Red Hat: same underlying code, different packaging, stability guarantees, and support.

Project State

SONiC is one of the healthier large-scale open-source networking projects. LF Insights reports 858 quarterly active contributors with 74% quarter-over-quarter retention across a diverse contributor base6. ONUG’s 2026 survey puts total active contributors at 4,300+ across 520+ organizations7. The GitHub organization sees ~9,900 PRs per month and commits on every day of the year.

The SONiC Foundation has 36+ members, including Premier members Arista Networks, Nokia, Broadcom, Microsoft, Google, Dell, Alibaba, Cisco, and NVIDIA8. Biannual releases ship each May and November; the latest, 202605, runs Debian Trixie with FRR 10.5, Redis 8, Python 3.13, and Linux Kernel 6.129.

Production deployments validate the project at scale: Microsoft Azure uses it for AI data center infrastructure, Alibaba Cloud runs 100,000+ white-box devices across 28 regions, SAKURA internet powered a TOP500 #49 supercomputer with an 800-GPU cluster, Rakuten Mobile achieved 50%+ cost savings in multi-vendor validation, and an Indian national payments network handles hundreds of millions of daily transactions on 300+ switches10.

Governance is neutral under the Linux Foundation with individual CLAs, public working groups, and formal release sign-off by the Governing Board. Core switching, BGP, VLANs, ACLs, and QoS are mature and well-tested. Management tooling — RESTCONF/gNMI coverage and OpenConfig model completeness — remains the main gap in community SONiC, which enterprise distributions fill for commercial customers.

Architecture

SONiC uses a microservices architecture where each network function runs in its own isolated Docker container. Containers never communicate directly. All inter-process communication flows through a central Redis key-value store accessed via UNIX socket. This pub/sub model enables fine-grained fault isolation, independent container upgrades, and clear separation of concerns.

Redis

The Redis engine is the nervous system of SONiC. It hosts multiple logical databases, each serving a distinct role in the control and data plane pipeline11.

Table 2: Redis databases in SONiC
Database Namespace Purpose
APPL_DB 0 Application state — routes, next-hops, neighbors, FDB entries. Southbound entry point for all applications
ASIC_DB 1 Hardware-level SAI representation of forwarding state. What gets programmed into silicon
COUNTERS_DB 2 Per-port and per-object packet/byte counters
CONFIG_DB 4 Desired configuration. Single source of truth
STATE_DB 6 Operational state for cross-module dependency resolution — e.g., port status before BGP starts

Containers

Each functional component runs in an independent Docker container, keeping high cohesion among related code while minimizing coupling between disjointed services12.

Core infrastructure containers
Container Description
database Runs the Redis daemon. All other containers access it through a UNIX socket
swss Switch State Service. Coordinates communication between modules
syncd Bridges software to hardware. Programs the ASIC through the SAI API
Control plane containers
Container Description
bgp FRR routing stack (BGP sessions)
lldp LLDP protocol with lldp_syncd writing state to Redis
teamd Link aggregation (LACP) with teamsyncd
snmp SNMP polling with snmp_subagent feeding collected data from Redis
dhcp-relay DHCP relay service
pmon Platform monitoring
eventd Event logging

Routing

The routing stack in SONiC is built on the open-source FRR project, running inside the bgp Docker container. Several FRR daemons work together inside this container:

  • bgpd — manages BGP sessions with peers, receives route advertisements, and applies policies
  • zebra — the route distribution daemon. It maintains the RIB (routing information base), runs the best-path selection across protocols, and pushes winning routes to the FIB (forwarding information base)
  • fpmsyncd — a SONiC-specific bridge between FRR and Redis. It watches zebra’s FIB updates via netlink and writes them into APPL_DB so the rest of the SONiC pipeline can consume them

The bgp container provides vtysh, an interactive CLI with an IOS-like interface for real-time configuration and troubleshooting. Community SONiC has no other built-in routing CLI. Configuration applied via vtysh lives inside the container’s FRR files. Alternatively, you can manage routing through SONiC’s config commands or config_db.json, which write to CONFIG_DB and flow through the standard Redis pipeline. The choice determines where configuration persists and which tools can manage it.

Data Flow

Understanding how data moves through the Redis pipeline clarifies how configuration reaches the hardware.

Example 1, programming a port:

  1. portsyncd (in swss) reads hardware profile config and writes port state to APPL_DB and STATE_DB
  2. orchagent is notified of APPL_DB changes, processes the data, and writes to ASIC_DB
  3. syncd receives the ASIC_DB update and programs the physical port via the SAI API and ASIC SDK
  4. The Linux kernel generates netlink events, which portsyncd picks up to mark initialization complete

Example 2, installing a route:

  1. bgpd collects routing updates from BGP peers
  2. Routes flow to zebra for RIB processing, redistribution, and kernel FIB updates
  3. fpmsyncd writes the resulting FIB state to APPL_DB
  4. orchagent processes the change and writes to ASIC_DB
  5. syncd programs the ASIC forwarding table via SAI

The pattern is consistent: application containers write to APPL_DB, orchagent translates to hardware-friendly state in ASIC_DB, and syncd executes the programming through SAI.

Configuration

Database Description
ConfigDB in Redis Running configuration of the device
config_db.json Startup configuration of the device

SONiC manages all device state through a single Redis database called ConfigDB, which acts as the authoritative source of truth13. Each containerized service — syncd, orchagent, FRR, SNMP, and others — subscribes to relevant ConfigDB keys and generates its own running configuration from them. Changing a value in ConfigDB propagates to every dependent component automatically.

The startup configuration persists on disk as /etc/sonic/config_db.json14. On boot, SONiC loads this JSON file into the Redis database.

config_db.json

A default config_db.json contains keys for port definitions, buffer profiles, QoS mappings, NTP servers, cable lengths, scheduler settings, and device metadata. Each key maps to a Redis hash; for example, PORT|Ethernet4 stores admin_status, speed, mtu, lanes, and description for that interface.

You can inspect ConfigDB directly with redis-cli:

# List all PORT keys (namespace 4 = CONFIG_DB)
redis-cli -n 4 keys "PORT*"

# Dump a specific port entry
redis-dump -d 4 -k "PORT|Ethernet4" -y

To apply a partial configuration change without touching the full file, write a JSON fragment and load it:

mgmt_ip.json
{
  "MGMT_INTERFACE": {
    "eth0|10.11.12.13/24": {
      "gwaddr": "10.11.12.1"
    }
  }
}
# Load and restart the management interface
config load mgmt_ip.json
systemctl restart interfaces-config

Because ConfigDB is the central control point, troubleshooting follows a clear path: verify the desired state in CONFIG_DB (namespace 4), check what the application received in APP_DB (namespace 0), then confirm ASIC programming in ASIC_DB (namespace 1). Mismatches at any stage indicate where the pipeline broke.

Command-Line

SONiC also has a simple Python Click based CLI interface. The config and show commands are the primary way operators interact with SONiC. All config commands require root privileges via sudo or a root shell.15

ImportantCLI Changes Are Not Persistent

Every config command writes to the running ConfigDB in Redis, so changes take effect immediately but are lost on reboot. Run sudo config save -y after your changes to write the running state back to /etc/sonic/config_db.json.

Here are common operations:

# Assign an IP to a port
sudo config interface ip set Ethernet0 10.0.0.1/31

# Add a BGP neighbor with AS number
sudo config bgp neighbor add 10.0.0.2 65001

# Create a VLAN
sudo config vlan add 100

# Running configuration (full ConfigDB dump)
show runningconfiguration all

sonic-cfggen

Behind the scenes, config save and config load are wrappers around sonic-cfggen, SONiC’s core configuration engine16. It reads from multiple sources — minigraph XML, JSON files, YAML files, and the live ConfigDB — merges them by priority, validates against the JSON schema, and writes to Redis. You can use it directly for advanced workflows:

# Dump ConfigDB to JSON
sudo sonic-cfggen -d --print-data > db_dump.json

# Load JSON into ConfigDB
sudo sonic-cfggen -j config.json --write-to-db

Automation

Managing a fleet of SONiC switches manually is not practical. SONiC offers three automation approaches, each suited to different operational needs.

Approach Transport Strengths Weaknesses
Ansible over SSH SSH + CLI / JSON push Broadest feature coverage; mature playbooks; no extra services required CLI-based collection lacks native idempotency; full JSON reloads are coarse-grained
RESTCONF HTTPS (port 443) Standard HTTP methods; Swagger UI for discovery; YANG-validated requests; easy integration with existing tooling Limited OpenConfig model coverage in community SONiC; no streaming telemetry
gNMI gRPC/HTTP2 (port 50051) Binary protocol buffers reduce overhead; bidirectional streaming telemetry; single connection for config and monitoring Steeper learning curve; same model coverage gaps as RESTCONF; fewer third-party clients

Use Ansible over SSH when you need broad feature coverage today and your team already works with playbooks. Use RESTCONF when you want standard HTTP APIs with YANG validation and an interactive testing UI. Use gNMI when streaming telemetry or high-frequency configuration pushes across many devices matters more than immediate feature breadth.

Ansible

SONiC’s native support JSON based configuration actions fit with Ansible-style automation. This pattern works because SONiC runs on Linux with native SSH access and a declarative JSON configuration model17.

A typical playbook renders Jinja2 templates into per-device JSON, copies the file, then reloads:

- name: Push config to SONiC switch
  hosts: sonic_switches
  become: true
  tasks:
    - name: Render config_db.json
      ansible.builtin.template:
        src: templates/config_db.json.j2
        dest: /tmp/config_db.json

    - name: Apply configuration
      ansible.builtin.command:
        cmd: config reload -y /tmp/config_db.json
      changed_when: true

Running a single command looks like the following:

- name: Leaf configuration
  gather_facts: false
  hosts: leaf_switches
  tasks:
   - name: Configure IP address for Ethernet0
     ansible.builtin.shell: config interface ip add Ethernet0 192.1.1.1/24
     become: True
   - name: Save config to /etc/sonic/config_db.json
     ansible.builtin.shell: config save -y
     become: True

Collections

Two well-maintained Ansible collections support SONiC:

  • cisco.sonic — for community SONiC, CLI-based modules over SSH18
  • dellemc.enterprise_sonic — for Dell Enterprise SONiC, declarative resource modules over RESTCONF19

The two collections differ fundamentally in how they reach the device and what kind of modules they provide.

The Dell collection’s resource modules express what the device should look like. The Cisco collection’s CLI modules express which commands to run. For infrastructure-as-code workflows where drift detection and safe re-runs matter, the resource-module approach is stronger. For quick one-off tasks or environments without RESTCONF available, the CLI approach remains practical.

Imperative

cisco.sonic connects over SSH using Ansible’s network_cli transport. Its modules — sonic_command, sonic_config, and FRR variants — send CLI commands to the switch and parse text output. This approach works against any community SONiC deployment since it requires no extra services. The trade-off is that idempotency depends on matching expected CLI output. If a SONiC update changes command formatting, playbooks can break unexpectedly. The collection has a small module surface and no declarative resource modules; planned future work includes REST and gNMI transports plus API-driven modules for BGP, ACL, and QoS.

Imperative approach required by cisco.sonic:

- name: Configure VLANs via CLI
  hosts: sonic_switches
  gather_facts: false
  connection: network_cli
  tasks:
    - name: Add VLANs
      cisco.sonic.sonic_config:
        lines:
          - "vlan add 701"
          - "vlan add 702"

    - name: Set interface IP
      cisco.sonic.sonic_config:
        lines:
          - "interface ip add Ethernet0 10.0.0.1/31"

Declarative

dellemc.enterprise_sonic supports two transports: network_cli for CLI commands and httpapi for RESTCONF. Its differentiator is the set of 40+ network resource modules — sonic_interfaces, sonic_bgp, sonic_vlans, sonic_l2_interfaces, sonic_qos_buffer, and others. These are declarative modules that accept a desired-state configuration and support merged, replaced, deleted, and overridden operations.

The module collects current state via RESTCONF, computes a diff, and sends only the necessary PATCH or DELETE calls. This provides true idempotency with check_mode support. The requirement is that the target runs Enterprise SONiC with the Management Framework REST service enabled.

A resource-module playbook from dellemc.enterprise_sonic declares intent rather than individual commands:

- name: Configure VLANs and interfaces
  hosts: sonic_switches
  gather_facts: false
  connection: httpapi
  tasks:
    - name: Create VLANs
      dellemc.enterprise_sonic.sonic_vlans:
        config:
          - vlan_id: 701
          - vlan_id: 702
        state: merged

    - name: Configure Layer 3 interface
      dellemc.enterprise_sonic.sonic_l3_interfaces:
        config:
          - name: Ethernet0
            ipv4:
              - address: 10.0.0.1/31
        state: replaced

HTTP/REST

SONiC’s Management Framework exposes a RESTCONF server — an HTTP-based API that follows RFC 8040 — for programmatic device configuration and state retrieval20. The RESTCONF endpoint listens on HTTPS port 443 by default and accepts standard HTTP methods: GET, POST, PUT, PATCH, and DELETE.

YANG Data Models

RESTCONF operates on YANG data models. YANG is a modeling language defined in RFC 7950 that describes structured configuration and state data for network devices. Think of it as a schema or type system: a YANG model defines what configuration nodes exist, their data types, valid ranges, required fields, and hierarchical relationships. The RESTCONF server uses these models to validate incoming requests before applying them, ensuring only structurally correct configurations reach the device.

SONiC ships with two families of YANG models:

  • OpenConfig — community-driven, vendor-neutral models covering interfaces, ACLs, LLDP, BGP, system, and platform data. These are the primary northbound models exposed through RESTCONF and gNMI21
  • sonic-* — custom models derived directly from SONiC’s internal Redis ABNF schema, covering port, interface, ACL, sFlow, and other SONiC-specific features22

A transformer component sits between the RESTCONF server and ConfigDB. When a request arrives using an OpenConfig model, the transformer translates the OpenConfig data tree into the equivalent SONiC Redis keys and vice versa for responses. This allows external tools to use standard OpenConfig paths while SONiC internally stores everything in its native format.

Enable the REST Server

The RESTCONF service is part of the mgmt-framework container. Enable it via CLI:

sudo config restconf enable
sudo systemctl restart mgmt-framework

An interactive Swagger UI is available at https://<switch-ip>/ui, which lists all supported YANG modules, their endpoints, and HTTP methods. It serves as both documentation and a testing console.

Request Examples

Discover supported YANG modules:

curl -sk https://admin:password@10.0.0.1/restconf/data/ietf-yang-library:modules-state \
  -H "Accept: application/yang-data+json" | jq

Get all interface configurations:

curl -sk https://admin:password@10.0.0.1/restconf/data/openconfig-interfaces:interfaces \
  -H "Accept: application/yang-data+json" | jq

Change the MTU on a specific interface:

curl -sk -X PATCH https://admin:password@10.0.0.1/restconf/data/openconfig-interfaces:interfaces/interface=Ethernet1/config/mtu \
  -H "Content-Type: application/json" \
  -d '{"mtu": 9200}'

A successful mutation returns HTTP 204 No Content. Verification follows with a GET to the same path.

Limitations

Community SONiC’s RESTCONF implementation covers a subset of YANG models. Core interfaces, ACLs, sFlow, and platform data work reliably, but coverage for advanced features like loopback interfaces and full BGP configuration remains incomplete23. Enterprise distributions from Dell and Broadcom extend support significantly through additional transformer modules and model implementations. For workflows requiring broad feature coverage today, Ansible over SSH or direct JSON manipulation remain more complete alternatives.

gNMI

gNMI (gRPC Network Management Interface) is a gRPC-based protocol defined by OpenConfig for device configuration, state retrieval, and streaming telemetry24. Unlike RESTCONF’s HTTP-over-TCP approach, gNMI uses HTTP/2 with protocol buffers (proto3) for binary serialization, yielding smaller message sizes and lower CPU overhead compared to JSON-over-HTTP. A single gRPC service handles both configuration management and continuous data streaming, eliminating the need for separate polling agents.

RPC Operations

The gNMI service defines four RPCs:

  • Capabilities — handshake to discover supported YANG models, encodings, and gNMI version
  • Get — retrieve a snapshot of configuration or state data for specified paths
  • Set — modify device state through update, replace, or delete operations
  • Subscribe — establish a long-lived stream for telemetry data, supporting ON_CHANGE, SAMPLE, and STREAM modes

SONiC implements all four RPCs across two layers. The older telemetry container (sonic-telemetry) provides gNMI access to Redis databases using native DB/Table/Key paths. The newer Management Framework adds YANG-aware gNMI through the same transformer used by RESTCONF, supporting OpenConfig and sonic-* models25.

Configuration

The gNMI server runs inside the telemetry container and listens on port 50051 by default. Enable it by adding a GNMI entry to ConfigDB:

gnmi_config.json
{
  "GNMI": {
    "certs": {
      "ca_crt": "/etc/sonic/telemetry/dsmsroot.cer",
      "server_crt": "/etc/sonic/telemetry/streamingtelemetryserver.cer",
      "server_key": "/etc/sonic/telemetry/streamingtelemetryserver.key"
    },
    "gnmi": {
      "client_auth": "true",
      "log_level": "2",
      "port": "50051"
    }
  }
}
sudo sonic-cfggen -j gnmi_config.json --write-to-db
sudo systemctl restart telemetry

The client_auth field controls whether TLS mutual authentication is required. Set to "false" for development environments with self-signed certificates.

Request Examples

SONiC ships CLI tools inside the telemetry container for testing. Enter the container with sudo docker exec -it telemetry bash.

Query supported capabilities:

gnmi_cli -insecure -with_user_pass -capabilities -address 127.0.0.1:50051

Get interface configuration using an OpenConfig path:

gnmi_get -insecure -username admin -password <pw> \
  -xpath /openconfig-interfaces:interfaces/interface[name=Ethernet0]/config \
  -target_addr 127.0.0.1:50051 -xpath_target OC-YANG

Set the MTU on an interface:

# mtu.json
{"mtu": 9108}

gnmi_set -insecure -username admin -password <pw> \
  -update /openconfig-interfaces:interfaces/interface[name=Ethernet0]/config/mtu:@./mtu.json \
  -target_addr localhost:8080 -xpath_target OC-YANG

Subscribe to operational state changes on an interface:

gnmi_cli -insecure -with_user_pass -address 127.0.0.1:50051 \
  -query_type s -streaming_type TARGET_DEFINED \
  -q /openconfig-interfaces:interfaces/interface[name=Ethernet0]/state/oper-status \
  -target OC-YANG

Streaming Telemetry

The Subscribe RPC is where gNMI offers capabilities REST cannot match. Instead of periodic polling, the switch pushes updates over a persistent gRPC stream whenever data changes. SONiC supports three subscription modes:

  • ON_CHANGE — sends an update only when the value changes, with optional heartbeat intervals
  • SAMPLE — sends data at fixed intervals regardless of changes
  • STREAM — sends all data at a target-defined rate, useful for high-frequency counters

Common use cases include streaming port counters, BGP state transitions, and link-up/link-down events to a central collector. The telemetry server also caches events when no client is connected and delivers them upon reconnection, preventing data gaps during brief collector outages.

Limitations

SONiC’s gNMI implementation mirrors the RESTCONF coverage gap: OpenConfig support for interfaces, ACLs, LLDP, and platform data works well, but advanced features like full BGP and VRF configuration are still being upstreamed. The dual-layer architecture — legacy telemetry container versus newer Management Framework — means some paths are accessible through one layer but not the other. Enterprise SONiC distributions extend coverage significantly. For production automation targeting broad feature sets, validating path support against your specific SONiC version is essential before relying on gNMI exclusively.

Upgrades & Lifecycle

Release Cadence

Community SONiC ships twice yearly — May and November — with version names encoding the release date (e.g., 202605 is the May 2026 release). Each release bumps the Debian base, kernel, FRR, Redis, Python, and SAI versions together. Recent progression: Bookworm (Debian 12) in 202405, Trixie (Debian 13) in 20260526.

Enterprise distributions follow a different cadence. Dell, Broadcom, and Asterfusion maintain extended support windows with regular patch drops between community releases. They backport security fixes and critical bug fixes without requiring a full version jump. An enterprise image might be labeled Dell_EnterpriseSONiC_1.7.0 rather than 202511, decoupling from the upstream release schedule while tracking a specific community baseline.

The practical difference: community SONiC requires you to plan upgrades around the biannual window or build custom images. Enterprise distributions give you predictable patch cycles with tested upgrade matrices between supported versions.

Image Management

SONiC manages OS images through sonic-installer, a CLI tool that handles installation, verification, and boot selection27. The switch stores up to two images on /dev/sda3. Installing a third automatically removes the oldest, keeping disk usage bounded.

# Install image from local file or remote URL
sudo sonic-installer install /tmp/SONiC-202605.bin
sudo sonic-installer install http://server/images/SONiC-202605.bin

# View installed images and boot pointers
sudo sonic-installer list

# Remove an unused image
sudo sonic-installer remove SONiC-202411.bin

# Clean up old images (keeps current + next only)
sudo sonic-installer cleanup

sonic-installer list shows Current (running now), Next (will boot after next reload), and Available (installed but not selected).

# Set as permanent default (survives all future reboots)
sudo sonic-installer set-default SONiC-202605.bin

# Set for next reboot only (one-time switch)
sudo sonic-installer set-next-boot SONiC-202605.bin

# Verify image integrity before committing
sudo sonic-installer verify-next-image

The distinction between set-default and set-next-boot matters for maintenance windows: set-next-boot lets you test a new image once without permanently changing boot order. If something goes wrong, a subsequent reboot returns to the previous default. Rollback is straightforward. Point set-default or set-next-boot at the previous image and reboot. No special recovery tools needed.

Enterprise difference: Dell Enterprise SONiC uses the same sonic-installer interface but adds image validation against the hardware platform. Attempting to install a non-Dell image on Dell PowerSwitch will fail. Broadcom Enterprise SONiC similarly validates image signatures and platform compatibility. Community SONiC places no such restrictions — any compatible image installs regardless of source.

Reboot Modes

Choosing the right reboot mode determines how much traffic disruption your upgrade causes. SONiC provides four modes, each trading off speed against safety guarantees.

Table 3: SONiC reboot modes compared
Mode Data Plane Impact Control Plane Recovery ASIC Reset Use Case
reload Full disruption until full boot Minutes Yes Major config changes, troubleshooting, initial deployment
warm-reboot None — forwarding continues Seconds to minutes No Routine upgrades, config reloads, container restarts
fast-reboot ~25–30 seconds <90 seconds Yes, fast init When ASIC state must refresh but downtime must stay minimal
express-reboot ~1 second Minimal No — NPU updated via DMA Minor revisions (same ASIC SDK); vendor-dependent support

Warm and fast reboot require LACP slow mode (30-second PDU intervals). LAGs configured in fast mode will flap during these operations. Express reboot is ASIC-vendor-dependent — currently available on Cisco 8000 series, Marvell Teralynx, and select NVIDIA platforms, not universally supported across community hardware.

All three reduced-downtime modes use kexec to skip BIOS/firmware initialization, loading the new kernel directly from memory. The shutdown sequence preserves state before the control plane stops:

  • Warm reboot saves ASIC_DB to disk. On restart, syncd restores the exact pre-reboot ASIC state without touching silicon. Neighbors see no interruption.
  • Fast reboot dumps FDB, ARP, and route tables to persistent storage. After kexec, syncd performs fast ASIC initialization, then SWSS replays saved entries in bulk. BGP graceful restart (RFC 4724) keeps neighbor sessions alive during the ~30-second data plane gap.
  • Express reboot avoids ASIC reset entirely. The control plane batches configuration deltas and pushes them to the NPU via direct memory access while forwarding continues. Limited to minor version jumps where punt/inject headers remain compatible.

Prerequisites apply across the board. LAGs must use LACP slow rate mode for warm and fast reboot. BGP neighbors should support graceful restart for fast reboot to work within the 90-second window. Verify neighbor capabilities before relying on reduced-downtime modes.

# Cold reboot (full disruption)
sudo reload -r now

# Warm reboot (no data plane impact)
sudo warm-reboot

# Fast reboot (<30s data plane, <90s control plane)
sudo fast-reboot

# Express reboot (~1s data plane, vendor-dependent)
sudo express-reboot

Check reboot history with show reboot-cause and show reboot-cause history. This helps diagnose whether an unexpected reboot was user-initiated, watchdog-triggered, or caused by a service failure.

Enterprise difference: Dell and Broadcom enterprise distributions validate the target image against a tested upgrade matrix before allowing warm or fast reboot. Community SONiC performs no such checks — it is your responsibility to verify compatibility between source and target versions. Enterprise distributions also provide rollback guidance per release, specifying which downgrade paths are safe.

Container Upgrades

Individual Docker containers can be upgraded without rebooting the entire system. This is useful for applying security patches to a single component or testing a new FRR version before committing to a full OS upgrade.

# Upgrade a specific container image
sudo sonic-installer upgrade-docker /path/to/new-container.tar

# Rollback a container to its previous version
sudo sonic-installer rollback-docker <container-name>

Each container supports warm restart independently. Restarting bgp regenerates FRR from ConfigDB without affecting routing on the ASIC. Restarting swss rebuilds orchagent state from APPL_DB. The database and syncd containers are exceptions — restarting them triggers full ASIC reprogramming.

Use container-level upgrades for targeted fixes. Use full image upgrades for coordinated releases where multiple components depend on each other’s changes.

Firmware Updates

Platform firmware — transceiver modules, PSUs, fans, and management controllers — lives outside the SONiC OS image. The fwutil command manages firmware inventory and updates28.

# List all firmware components and versions
sudo fwutil show all

# Update a specific component
sudo fwutil update <component-id> /path/to/firmware.bin

# Update all components matching platform_components.json
sudo fwutil update all

fwutil update all reads platform_components.json, a vendor-supplied manifest that maps each hardware component to its firmware package and update requirements. Components that need no reboot update immediately. Components requiring a reboot schedule their update for the next warm, fast, or cold reboot based on the configured reboot-type field. Status is visible with fwutil show update status.

Transceiver firmware follows the same model. Plugged-in modules are discovered automatically, and fwutil compares running firmware against the manifest to identify outdated components. Some transceivers update in-place; others require unplug/replug cycles.

Enterprise difference: Enterprise distributions ship pre-validated platform_components.json files with known-good firmware bundles matched to each hardware SKU. Community SONiC relies on platform API implementations from hardware vendors, which may have incomplete firmware manifests or lack automated update paths for certain components. Dell Enterprise SONiC integrates firmware updates into its management framework, allowing firmware and OS upgrades to execute as a coordinated operation with pre-flight validation.

Footnotes

  1. SONiC Project
    https://sonicfoundation.dev/
    https://www.youtube.com/@sonic-fund↩︎

  2. SONiC on GitHub
    https://github.com/sonic-net/SONiC↩︎

  3. Switch Abstraction Interface (SAI)
    https://github.com/opencomputeproject/SAI↩︎

  4. SONiC Architecture and Ecosystem — Cisco Live 2025 BRKMSI-2004
    https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2025/pdf/BRKMSI-2004.pdf↩︎

  5. SONiC Community Releases
    https://github.com/sonic-net/sonic-buildimage↩︎

  6. SONiC Foundation — LF Insights
    https://insights.linuxfoundation.org/project/sonic-foundation↩︎

  7. State of Enterprise SONiC Adoption — ONUG, February 2026
    https://onug.net/blog/state-of-enterprise-sonic-adoption-the-open-networking-shift-accelerates-in-ai-era/↩︎

  8. SONiC Foundation Announcements
    https://sonicfoundation.dev/announcements/↩︎

  9. SONiC Contributor Guide — Release Schedule
    https://github.com/sonic-net/SONiC/wiki/Becoming-a-contributor↩︎

  10. SONiC Foundation Accelerates Ecosystem Growth — LF Press Release, October 2025
    https://www.linuxfoundation.org/press/sonic-foundation-accelerates-ecosystem-growth-and-global-adoption-as-the-leading-open-source-nos-optimized-for-enterprise-ai-workloads↩︎

  11. SONiC Multi-Database Instances
    https://github.com/sonic-net/SONiC/blob/master/doc/database/multi_database_instances.md↩︎

  12. SONiC Architecture Wiki
    https://github.com/sonic-net/SONiC/wiki/Architecture↩︎

  13. SONiC Configuration Wiki
    https://github.com/sonic-net/SONiC/wiki/Configuration↩︎

  14. SONiC Configuration Wiki
    https://github.com/sonic-net/SONiC/wiki/Configuration↩︎

  15. Command Reference
    https://github.com/sonic-net/sonic-utilities/blob/master/doc/Command-Reference.md↩︎

  16. Configuration Engine (sonic-cfggen)
    https://deepwiki.com/sonic-net/sonic-buildimage/5.1-configuration-engine-(sonic-cfggen)↩︎

  17. Cisco Live DEVNET-2990: Automate SONiC Configuration using Ansible
    https://www.ciscolive.com/c/dam/r/ciscolive/global-event/docs/2025/pdf/DEVNET-2990.pdf↩︎

  18. Cisco SONiC Ansible Collection
    https://galaxy.ansible.com/ui/repo/published/cisco/sonic/↩︎

  19. Dell Enterprise SONiC Ansible Collection
    https://docs.ansible.com/projects/ansible/latest/collections/dellemc/enterprise_sonic/index.html↩︎

  20. SONiC Management Framework Design
    https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/Management%20Framework.md↩︎

  21. OpenConfig Yang Models
    https://github.com/openconfig/public/tree/master/release/models↩︎

  22. SONiC YANG Models, GitHub
    https://github.com/sonic-net/sonic-buildimage/tree/master/src/sonic-yang-models/yang-models↩︎

  23. Incomplete REST API Support for YANG Models — SONiC Issue #15183
    https://github.com/sonic-net/sonic-buildimage/issues/15183↩︎

  24. gNMI Specification
    https://github.com/openconfig/reference/blob/master/rpc/gnmi/gnmi-specification.md↩︎

  25. SONiC gNMI Server Interface Design
    https://github.com/sonic-net/SONiC/blob/master/doc/mgmt/gnmi/SONiC_GNMI_Server_Interface_Design.md↩︎

  26. SONiC Contributor Guide — Release Schedule
    https://github.com/sonic-net/SONiC/wiki/Becoming-a-contributor↩︎

  27. SONiC Installer — User Manual
    https://github.com/sonic-net/SONiC/blob/master/doc/user-manual/SONiC-User-Manual.md↩︎

  28. SONiC Firmware Utility Design
    https://github.com/sonic-net/SONiC/blob/master/doc/fwutil/fwutil.md↩︎