SONiC config_db.json: Edit and Apply Configuration Safely

Every SONiC configuration question eventually arrives at one file: /etc/sonic/config_db.json. Understanding how that file relates to the CLI, to Redis and to the running state is what separates an operator who can recover a switch from one who reloads it and hopes. This guide explains the three configuration paths and the workflow that keeps them consistent.

Three ways to configure SONiC

• CLI — config commands change the live CONFIG_DB in Redis.
• config_db.json — the persisted JSON representation, loaded at boot and by config reload.
• Minigraph — a topology-described deployment model used by some large-scale fabrics.

Crucially, the CLI and the JSON file are not the same store. A CLI change is live and in Redis immediately, but it is not durable until saved. A JSON edit changes nothing until it is loaded.

The CLI-to-durable path

config interface ip add Ethernet0 10.0.0.1/30
config vlan add 100
config vlan member add 100 Ethernet4
show vlan brief              # live state, from Redis
config save /etc/sonic/config_db.json

config save serialises the current CONFIG_DB into config_db.json, which is what survives a reboot. Skip it and the switch returns to its previous configuration after the next reload — with no warning at the time of the change.

Loading a file

config reload /etc/sonic/config_db.json
# or, after editing
config load /etc/sonic/config_db.json --yes

config reload rebuilds services from the file and interrupts forwarding. config load merges the file into the running CONFIG_DB without a full reload, which is gentler but easier to get wrong. Choose deliberately.

Looking at the databases directly

redis-cli -n 4 KEYS 'VLAN*'
redis-cli -n 4 HGETALL 'VLAN|100'
redis-cli -n 4 HGETALL 'VLAN_MEMBER|Vlan100|Ethernet4'
docker exec -it swss sonic-cfggen -d --print-data

CONFIG_DB is Redis database 4. Reading it directly is the fastest way to prove what the system believes, and it is the reason a hand-edit of the JSON file does not immediately change behaviour — the file is an input to a process, not the running state.

A safe change workflow

1. Back up the current file: cp /etc/sonic/config_db.json /etc/sonic/config_db.json.bak.
2. Make changes with config commands wherever a command exists.
3. Verify with the matching show command.
4. config save, then confirm the diff.
5. Keep the file in version control so rollback is a copy and a reload, not a rebuild.

Hand-editing JSON is legitimate for bulk provisioning or for keys the CLI does not expose — but validate the JSON before loading it, and treat a syntax error in that file as a device that boots into a partially configured state.

Related reading: SuzieQ network observability, Nautobot source of truth deployment, Dell OS10 zero-touch provisioning.

原文链接：https://netbergtw.com/top-support/netberg-sonic/configuring-sonic-using-cli-or-editing-json/