Sonic-Architecture

 

SONiC's architecture is built around one central idea: Redis as the system bus. Every daemon — whether it handles routing, port management, or ASIC programming — communicates exclusively by reading from and writing to Redis databases. No daemon calls another daemon directly. This makes the system modular, debuggable, and loosely coupled.

Let's start with the big picture — how the layers stack from user CLI down to the ASIC.

The data flows strictly top-down: CLI writes to CONFIG_DB → *mgrd daemons pick it up and write to APPL_DB → orchagent translates to SAI objects and writes to ASIC_DB → syncd reads ASIC_DB and programs the hardware. Now let's look at each daemon layer in detail.

The *mgrd daemons — config translators

These daemons live in the swss Docker container. They watch CONFIG_DB for changes and translate configuration into kernel/application state, also publishing to APPL_DB.

swss container — switch state service

Daemon     What it does                                                                                                Reads                      Writes

portmgrd Configures physical port attributes: speed, MTU, admin state, FEC. Applies via kernel netlink and APPL_DB.    CONFIG_DB PORT              APPL_DB PORT_TABLE

intfmgrd Manages L3 interface IP assignments. Creates kernel interfaces, handles loopbacks and sub-interfaces.        CONFIG_DB INTF_TABLE          APPL_DB INTF_TABLE

vlanmgrd Creates/deletes VLAN bridge interfaces in kernel. Adds/removes member ports to VLANs.                        CONFIG_DB VLAN,VLAN_MEMBER APPL_DB VLAN_TABLE

teammgrd Manages LAG/port-channel interfaces using teamd. Handles LACP configuration and member port bonding.        CONFIG_DB PORTCHANNEL      APPL_DB LAG_TABLE

nbrmgrd     Manages neighbor (ARP/NDP) entries. Watches kernel neighbor table and syncs to APPL_DB for orchagent.        STATE_DB, kernel              APPL_DB NEIGH_TABLE

vrfmgrd     Creates VRF (Virtual Routing and Forwarding) instances in the kernel and tracks them in APPL_DB.            CONFIG_DB VRF              APPL_DB VRF_TABLE

tunnelmgrd Manages VXLAN and IP-in-IP tunnel interfaces. Creates kernel tunnel devices and maps in APPL_DB.            CONFIG_DB VXLAN_TUNNEL      APPL_DB TUNNEL_TABLE

Click any row to dive deeper into a specific daemon. Here's how the full data pipeline works end-to-end when you configure something:

Tracing a config change — example: config interface ip add Ethernet0 192.168.1.1/24

1. The CLI writes INTF_TABLE|Ethernet0 with IP 192.168.1.1/24 into CONFIG_DB (DB 4).
2. intfmgrd sees the change via Redis pub/sub, creates the kernel interface using netlink, and writes to APPL_DB (DB 0) INTF_TABLE:Ethernet0.
3. orchagent subscribes to APPL_DB, picks up the INTF entry, creates a SAI router interface object, and writes ASIC_STATE:SAI_OBJECT_TYPE_ROUTER_INTERFACE:oid:0x... to ASIC_DB (DB 1).
4. syncd reads from ASIC_DB and calls the vendor SAI library (sai_router_interface_api->create_router_interface()), which programs the ASIC forwarding table.
5. STATE_DB (DB 7) gets updated with the operational status, which is what show interface status reads.

Key diagnostic commands

sh

docker ps                                 # see all running containers
docker exec swss supervisorctl status     # all daemons in swss container
docker exec syncd supervisorctl status    # syncd status

# Watch a config flow live
docker exec database redis-cli -n 4 subscribe __keyevent@4__:hset
docker exec database redis-cli -n 0 subscribe __keyevent@0__:hset

# Check orchagent logs
docker exec swss tail -f /var/log/swss/orchagent.log

# Check if a route made it to ASIC
docker exec database sonic-db-cli ASIC_DB keys "ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY*"

The beauty of this design is that every step is observable in Redis — if something doesn't reach the ASIC, you can pinpoint exactly which stage it got stuck at by checking CONFIG_DB → APPL_DB → ASIC_DB in sequence.