On this page
Databases and the Configuration-to-Forwarding Path
Separate intent, derived application state, and programming evidence—then trace two concrete examples.
- Explain the different questions answered by the main databases.
- Trace a VLAN configuration and a learned route without merging their origins.
- Interpret a database entry as one piece of evidence.
One engine, several meanings
SONiC uses Redis logical databases and structured tables to exchange state. A table entry typically has a key and field/value pairs. Names such as CONFIG_DB describe a role, not a stage that every event must visit. Different services produce and consume different tables; one service can do both.
| Database | What it represents | Example relationship |
|---|---|---|
| CONFIG_DB | Running configuration intent | Management tools write configuration; managers and relevant orchestration components consume it. |
| APPL_DB | Application-level state for networking objects | fpmsyncd produces route state; neighbor synchronization produces neighbor state; orchestration consumes relevant tables. |
| ASIC_DB | SAI-oriented object state and operation transport in the conventional Redis design | SAI Redis and syncd exchange programming operations and related state. |
| STATE_DB | Operational and dependency information | Services publish readiness or observed state; other services use relevant information to coordinate work. |
| COUNTERS_DB | Collected statistics and supporting mappings | Counter collection populates data consumed by show commands and monitoring. |
This is a useful subset, not a complete database inventory. Instance layout and namespaces can differ on multi-ASIC systems. Use database names with image-supported tooling instead of assuming a numeric Redis index or a single global instance.
Read further: SWSS database schema definitions · Neighbor synchronization implementation · SONiC architecture.
Example A: a VLAN configuration
Suppose an operator adds a VLAN and a member port using a supported configuration interface. The intended VLAN and membership appear in CONFIG_DB. In a common implementation, vlanmgrd consumes those tables, manages related Linux bridge/interface state, and publishes application state. Orchestration then handles the relevant forwarding objects.
The dependency matters: an intended member port must refer to an available port. Creating a key does not make that dependency disappear. Some features have orchestration components that consume CONFIG_DB directly, so do not turn the VLAN example into a rule that every configuration must be copied through APPL_DB.
Running configuration and saved startup configuration also differ. /etc/sonic/config_db.json is commonly the startup configuration file; supported save/load workflows control persistence. A running change should not be assumed to survive a reboot.
Read further: VLAN manager implementation · Configuration database & models.
Example B: a BGP-learned route
A dynamically learned route does not need a matching CONFIG_DB key for its prefix. BGP configuration may establish the session and policy, but the route itself originates in protocol state. On the illustrated route path, zebra exports forwarding updates through FPM; fpmsyncd publishes application route state. RouteOrch, part of orchagent, processes routes and their dependencies.
For the conventional SAI Redis path, orchagent calls the SAI API through the Redis client library. Serialized operations cross the ASIC_DB boundary; syncd processes them and calls vendor SAI. The ASIC_DB representation is not an independent readback of every hardware table. Success at one software boundary does not prove end-to-end delivery.
Read further: RouteSync implementation · Route orchestration implementation · SAI Redis & syncd · syncd implementation.
Read intent without changing it
sonic-db-cli CONFIG_DB HGETALL 'PORT|Ethernet0'Read-only command example, not executed. Requires suitable permissions and the correct database namespace.
admin_status
up
mtu
9100Illustrative shortened response only. Port name, fields, formatting, and values are not observations from a device.
This example says the configured administrative status is up. It says nothing by itself about carrier, a resolved neighbor, or a particular packet. For a conventional application route table, an investigation might also inspect sonic-db-cli APPL_DB HGETALL 'ROUTE_TABLE:203.0.113.0/24'; verify the actual VRF, key format, and transport for the chosen image first.
Read further: Configuration database & models · fpmsyncd implementation.
Key takeaways
- The main databases answer different questions; they are not one universal pipeline.
- Configuration and learned routes have different origins and consumers.
- Dependency resolution and asynchronous processing affect when state becomes usable.
- ASIC_DB state alone does not prove successful hardware forwarding.
- Use read-only evidence from the correct release, instance, VRF, and packet path.
Check your understanding
Six questions, four choices each. Check each answer for an explanation, then review your score and retry.
Official references
Reviewed 18 October 2026. Living upstream references describe several generations of SONiC; match operational details to the selected release. Implementation links support the examples, not a claim that every image runs current master.