SWSS, Orchagents, syncd & ASIC_DB

SWSS and the orchagents

SWSS (Switch State Service) is the container that hosts the orchestration logic. Inside it, the orchagent process runs a set of feature-specific orchestration agents (orchagents) — for example port, interface, neighbor, route, FDB, VLAN, and ACL orchagents (routeorch, neighorch, intfsorch, portsorch, fdborch, vlanorch, aclorch, and others).

Each orchagent subscribes to the relevant application state (largely APPL_DB, populated from CONFIG_DB by the *Mgr daemons and from FRR by fpmsyncd for routes). It converts that desired state into SAI object operations. Crucially, it does this in dependency order and retries when references are not yet available.

Dependency management

SAI objects reference each other, so order matters. A route entry cannot be created before its next hop; a next hop needs its router interface; the router interface needs its port; a next hop's forwarding needs a resolved neighbor (MAC). Orchagents encode these dependencies: they hold pending work until references exist, then program it, and they react to changes (a neighbor resolving, a port coming up) by completing previously blocked operations.

This is why a change can 'stall halfway': the top-level object (a route) is waiting on a dependency (an unresolved neighbor) that never arrives. The route exists as intent but is not fully programmed to forward.

syncd, the vendor SAI, and the SDK

syncd is the process/container that owns the SAI interface to the chip. Orchagents do not call the vendor library directly; they hand object operations to syncd (over the databases/messaging), and syncd invokes the vendor SAI implementation, which calls the vendor SDK, which performs the actual hardware programming. On a vendor image these lower layers are vendor-provided binaries; on SONiC-VS they are a *virtual* SAI that emulates behavior and does not reproduce a real ASIC.

syncd also manages the OID mapping: SONiC uses virtual object IDs (VIDs) in ASIC_DB, while the SAI implementation uses real IDs (RIDs). syncd maintains the VID↔RID translation (visible as the VIDTORID/RIDTOVID maps in ASIC_DB) so the abstract graph in the database corresponds to real handles in the implementation.

Illustrative: an ASIC_DB route object and its VID→RID map

# ASIC_DB is redis DB 1. Scan just the route entries:
redis-cli -n 1 SCAN 0 MATCH 'ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY*' COUNT 200
# 1) "ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY:{...\"dest\":\"10.20.0.0/24\"...}"

# Inspect that object's attributes (note it references a next hop by VID):
redis-cli -n 1 HGETALL 'ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY:{...10.20.0.0/24...}'
# SAI_ROUTE_ENTRY_ATTR_PACKET_ACTION -> SAI_PACKET_ACTION_FORWARD
# SAI_ROUTE_ENTRY_ATTR_NEXT_HOP_ID   -> oid:0x4000000000abc   (a VID)

# Translate that virtual OID to the implementation's real OID:
redis-cli -n 1 HGET VIDTORID oid:0x4000000000abc
# -> oid:0x9a00000012   (the vendor SAI's real handle)

Targeted SCAN, not KEYS *. Values are illustrative and abbreviated; real keys/attributes vary by version and ASIC.

Notifications and counters flowing back up

The path is not one-way. The SAI implementation raises notifications (port state up/down, FDB learn/age events, and others) that syncd surfaces so orchagents and STATE_DB reflect reality. Separately, a flex counter mechanism periodically polls SAI statistics (per port, queue, ACL entry, etc.) and writes them to COUNTERS_DB, which is what show interfaces counters and friends read.

So there are three distinct 'return' channels to keep straight: acknowledgements (did the SAI call succeed), notifications (asynchronous hardware events), and counters (periodic statistics). A forwarding problem shows up differently in each — a call can succeed, yet counters show drops, or a notification (port down) can invalidate an otherwise-programmed path.