Expert coverage of SONiC (Software for Open Networking in the Cloud): Redis database architecture, SAI abstraction layer, SwSS orchestration, syncd, FRRouting BGP/OSPF, ConfigDB/YANG, KLISH CLI, DASH SmartNIC offload, whitebox hardware, and enterprise SONiC deployments. Use for \"SONiC\", \"SAI\", \"SwSS\", \"syncd\", \"ConfigDB\", \"ASIC_DB\", \"SONiC CLI\", \"whitebox switch\", \"SONiC DASH\", \"SONiC BGP\". Do NOT use for cross-vendor comparison, platform selection, or category-wide archit...
$npx -y skills add chrishuffman5/domain-expert --skill sonic --agent claude-code
Installs into .claude/skills of the current project.
Are you the author of Sonic?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/chrishuffman5-sonic)
---
name: sonic
description: "Expert coverage of SONiC (Software for Open Networking in the Cloud): Redis database architecture, SAI abstraction layer, SwSS orchestration, syncd, FRRouting BGP/OSPF, ConfigDB/YANG, KLISH CLI, DASH SmartNIC offload, whitebox hardware, and enterprise SONiC deployments. Use for \"SONiC\", \"SAI\", \"SwSS\", \"syncd\", \"ConfigDB\", \"ASIC_DB\", \"SONiC CLI\", \"whitebox switch\", \"SONiC DASH\", \"SONiC BGP\". Do NOT use for cross-vendor comparison, platform selection, or category-wide architecture -- use the `dc-fabric` skill."
license: MIT
---
# SONiC
This skill covers SONiC (Software for Open Networking in the Cloud) across community and enterprise distributions. Areas of expertise include:
- Redis-centric architecture: CONFIG_DB, APP_DB, ASIC_DB, STATE_DB, pub/sub event model
- SAI (Switch Abstraction Interface): Hardware abstraction, vendor libsai implementations, ASIC programming
- SwSS (Switch State Service): orchagent orchestration, daemon architecture (neighsyncd, portsyncd, intfsyncd, routesyncd)
- syncd: ASIC_DB to hardware bridge, vendor SAI library integration, ASIC notifications
- FRRouting (FRR): BGP, OSPF, IS-IS, static routing, route redistribution, ECMP
- ConfigDB and YANG models: config_db.json, sonic-cfggen, model-driven validation, gNMI/RESTCONF
- CLI: Legacy show/config commands, KLISH (IOS-like CLI), sonic-cli
- SONiC-DASH: SmartNIC/DPU offload, SAI-like APIs for VNET routing, NAT, LB
- Whitebox hardware: OCP switches, ODM vendors (Dell, Edgecore, Celestica, Accton, UfiSpace)
- Supported ASICs: Broadcom (Trident/Tomahawk), NVIDIA/Mellanox (Spectrum), Marvell, Intel Tofino
- Automation: Ansible (network.sonic), Terraform, gNMI, RESTCONF
## How to Approach Tasks
1. **Classify** the request:
- **Architecture** -- Load `references/architecture.md` for Redis, SAI, SwSS, syncd internals
- **Configuration** -- ConfigDB manipulation, CLI commands, YANG model usage
- **Routing** -- FRR configuration, BGP design, ECMP, VXLAN/EVPN overlay
- **Hardware selection** -- ASIC capabilities, ODM vendor comparison, SAI feature support
- **Troubleshooting** -- Database inspection, service logs, SAI counters, FRR debug
- **Automation** -- gNMI, RESTCONF, Ansible, Terraform, sonic-cfggen
- **DASH / SmartNIC** -- DPU offload architecture, DASH SAI APIs
2. **Identify ASIC platform** -- Different ASICs have different SAI feature coverage. Broadcom Tomahawk vs NVIDIA Spectrum vs Marvell Prestera matters for feature availability.
3. **Load context** -- Read `references/architecture.md` for deep architectural knowledge.
4. **Analyze** -- Apply SONiC-specific reasoning. Consider the Redis database flow (CONFIG_DB -> APP_DB -> ASIC_DB -> hardware) and identify where issues occur.
5. **Recommend** -- Provide actionable guidance with CLI commands, ConfigDB JSON, or FRR configuration.
6. **Verify** -- Suggest validation steps (show commands, Redis queries, FRR status).
## Architecture Overview
### Data Flow
```
Operator / Automation
|
v
CONFIG_DB (desired state)
|
v
SwSS / orchagent (translates config to application state)
|
v
APP_DB (application-derived state)
|
v
orchagent (translates app state to SAI objects)
|
v
ASIC_DB (SAI object requests)
|
v
syncd (calls vendor SAI library)
|
v
ASIC Hardware (forwarding tables programmed)
|
v
STATE_DB (operational state feedback: link up/down, counters)
```
### Redis Databases
| Database | Purpose | Written By | Read By |
|---|---|---|---|
| **CONFIG_DB** | Desired configuration | Operators, automation, CLI | SwSS daemons |
| **APP_DB** | Application-derived state | FRR (routes), DHCP, LLDP daemons | orchagent |
| **ASIC_DB** | Hardware programming requests | orchagent | syncd |
| **STATE_DB** | Operational state | syncd, kernel drivers | CLI, monitoring |
| **COUNTERS_DB** | Port/queue statistics | syncd | CLI, telemetry |
| **FLEX_COUNTER_DB** | Flexible counter configuration | CONFIG_DB triggers | syncd |
### Key Daemons
| Daemon | Role |
|---|---|
| **orchagent** | Main orchestrator; translates CONFIG_DB/APP_DB to ASIC_DB |
| **syncd** | Programs ASIC hardware via vendor SAI library |
| **bgpd (FRR)** | BGP routing protocol |
| **zebra (FRR)** | Routing table manager; installs routes into kernel and APP_DB |
| **neighsyncd** | Synchronizes neighbor table (ARP/NDP) to ASIC |
| **portsyncd** | Synchronizes port configuration to ASIC |
| **intfsyncd** | Synchronizes interface IP addresses to ASIC |
| **teamd** | LAG/LACP management |
| **lldpd** | LLDP neighbor discovery |
## SAI (Switch Abstraction Interface)
SAI is the critical hardware abstraction between SONiC and ASIC silicon:
- Standardized C API for hardware operations: create/delete/modify forwarding tables, port attributes, tunnels
- Each ASIC vendor provides a **SAI implementation (libsai)** specific to their silicon
- SONiC application code never calls ASIC directly; always through SAI
### Supported ASICs
| Vendor | Silicon Families | Typical Use |
|---|---|---|
| **Broadcom** | Trident 2/3/4, Tomahawk 2/3/4, Jericho | DC leaf/spine, carrier |
| **NVIDIA/Mellanox** | Spectrum 1/2/3/4 | DC fabric, AI/ML networking |
| **Marvell** | Prestera (98CX), AlleyCat (98DX) | Enterprise, campus |
| **Intel** | Tofino (P4-programmable) | Programmable forwarding |
| **Innovium** | TERALYNX | High-performance DC |
### SAI Feature Coverage
Not all features are available on all ASICs. Key differences:
- **VXLAN/EVPN** -- Broadcom Trident 3+ and Spectrum 2+ have mature support
- **PBR (Policy-Based Routing)** -- Varies by ASIC; check SAI capabilities
- **ACL scale** -- TCAM size differs significantly between ASICs
- **ECMP groups** -- Maximum ECMP paths differ by silicon
- **Queue/QoS** -- Queue count and scheduling granularity vary
## CLI
### Legacy CLI (show/config)
```bash
# System information
show version # SONiC version, platform, ASIC
show platform summary # Hardware platform details
# Interfaces
show interfaces status # All interface operational status
show interfaces counters # Packet/byte counters per interface
show interfaces portchannel # LAG/PortChannel status
# Routing
show ip route # IP routing table (kernel)
show ip bgp summary # BGP neighbor summary (FRR)
show ip bgp neighbors <ip> # Detailed BGP neighbor info
show ip bgp network # BGP advertised networks
# L2
show vlan brief # VLAN configuration and membership
show mac # MAC address table
# Configuration
config interface ip add Ethernet0 192.168.1.1/24
config interface startup Ethernet0
config vlan add 100
config vlan member add 100 Ethernet4
config save # Persist to /etc/sonic/config_db.json
config load /etc/sonic/config_db.json
config reload # Reload config (service restart)
```
### KLISH CLI (sonic-cli)
KLISH provides a familiar IOS-like hierarchical CLI:
```
sonic# configure terminal
sonic(config)# interface Ethernet 0
sonic(conf-if-Ethernet0)# ip address 192.168.1.1/24
sonic(conf-if-Ethernet0)# no shutdown
sonic(conf-if-Ethernet0)# exit
sonic(config)# router bgp 65001
sonic(config-router-bgp)# neighbor 192.168.1.2 remote-as 65002
```
Available in newer SONiC builds and enterprise distributions (Dell, Edgecore/STORDIS).
## ConfigDB and YANG
### config_db.json
All SONiC configuration is stored in `/etc/sonic/config_db.json`:
```json
{
"INTERFACE": {
"Ethernet0|192.168.1.1/24": {}
},
"VLAN": {
"Vlan100": {
"vlanid": "100"
}
},
"VLAN_MEMBER": {
"Vlan100|Ethernet4": {
"tagging_mode": "untagged"
}
},
"BGP_NEIGHBOR": {
"192.168.1.2": {
"asn": "65002",
"name": "spine1"
}
}
}
```
### YANG Models
- SONiC maintains YANG data models for all features
- Enable model-driven configuration validation
- Support gNMI and RESTCONF management interfaces
- `sonic-cfggen` converts between ConfigDB JSON and YANG representations
### gNMI / RESTCONF
- **gNMI** -- gRPC-based network management; supports Get, Set, Subscribe operations
- **RESTCONF** -- RESTful interface using YANG models
- Both enable model-driven automation without SSH/CLI scraping
## SONiC-DASH
DASH (Disaggregated API for SONiC Hosts) extends SAI to SmartNICs and DPUs:
- Defines SAI-like APIs for: VNET routing, NAT, load balancing, ACL, metering
- Functions executed on programmable NICs (NVIDIA BlueField, etc.)
- **Use cases**: Cloud-native LB offload, virtual network gateway offload, SDN data plane on host
- Implemented by Microsoft Azure (SmartNICs for Azure SDN)
## Whitebox Hardware
### OCP-Compatible Switches
| Vendor | Series | Notes |
|---|---|---|
| **Dell** | S52xx, S54xx | Dell Enterprise SONiC available |
| **Edgecore** | AS9516, AS7726, ECS4100 | STORDIS provides commercial support |
| **Celestica** | DX010, DS4000 | OCP designs |
| **UfiSpace** | S9600 | Carrier-grade |
| **Supermicro** | SSE series | Enterprise focus |
### Enterprise SONiC Distributions
Several vendors offer commercially supported SONiC:
- **Dell Enterprise SONiC** -- Dell-supported distribution for Dell switches
- **STORDIS** -- Edgecore-backed commercial SONiC support
- **Microsoft SONiC** -- Azure-internal distribution (not commercially sold)
- **Alibaba SONiC** -- Large-scale production (100,000+ devices)
## Common Pitfalls
1. **Assuming all SAI features work on all ASICs** -- SAI feature coverage varies by vendor and silicon generation. Always verify feature support for your specific ASIC before deployment.
2. **Editing config_db.json without config reload** -- Changes to the JSON file are not applied until `config reload` or `config load`. Direct Redis writes bypass validation.
3. **Ignoring FRR version** -- SONiC bundles a specific FRR version. BGP features (e.g., extended communities, flowspec) depend on the FRR version, not the SONiC version.
4. **VXLAN without adequate ECMP** -- SONiC VXLAN/EVPN requires proper ECMP hashing. Verify that the ASIC supports the required hash fields (inner headers for VXLAN).
5. **Not monitoring Redis databases** -- Redis is the nervous system of SONiC. Monitor CONFIG_DB, APP_DB, and ASIC_DB for inconsistencies that indicate programming failures.
6. **Treating SONiC like a traditional NOS** -- SONiC's database-driven architecture is fundamentally different from Cisco/Arista CLI-driven models. Embrace ConfigDB/YANG-driven workflows rather than fighting the architecture.
7. **Missing ASIC counters in troubleshooting** -- Always check both kernel-level counters (`show interfaces counters`) and SAI-level counters for packet drops. Drops can occur at the SAI/ASIC level without appearing in kernel stats.
## Reference Files
Load these when you need deep knowledge:
- `references/architecture.md` -- Redis database architecture, SAI internals, SwSS daemon details, syncd, FRR integration, ConfigDB/YANG models, DASH. Read for "how does X work" questions.