SONiC OS CLI Cheat Sheet: Commands That Matter

SONiC is not a single CLI the way EOS or NX-OS is — it is a collection of Linux processes holding a Redis-backed configuration database, wrapped in a platform-independent command set. Engineers arriving from a traditional network OS find the show commands familiar and everything else unfamiliar. This cheat sheet covers the commands that carry most of the daily operational weight: interface and counter inspection, VLAN and port configuration, the config save workflow that decides whether a change survives a reboot, and the container-level checks that explain why a feature is not working.

Interfaces and counters

show interfaces status
show interfaces counters
show interfaces counters errors
show interfaces description
show ip interfaces
show ip route
show ip bgp summary
show lldp neighbors
show mac
show vlan brief

Start every fault with show interfaces status; a port that is administratively up but operationally down is a physical or peer-problem, and one that is up with a high error counter is a cable, optic or speed/duplex issue. show interfaces counters errors isolates CRC from runts and giants, which is the difference between a bad optic and a duplex or MTU mismatch.

Configuration: config_db, not running-config

SONiC separates the running configuration (per-container) from the persistent database. Changes made with config commands load into CONFIG_DB, and must be saved or they vanish on reboot:

configure terminal
interface Ethernet0
    description UPLINK-to-SPINE1
    mtu 9100
    exit
interface Ethernet0
    switchport trunk allowed vlan 10,20
    exit
vlan 10
vlan 20
exit

Then the step that catches everyone:

sudo config save -y
show runningconfiguration all

Without config save, a reboot silently reverts the device to the last saved config_db.json. To push an entire configuration as a file, use config load <file> -y, or config reload -y to rebuild the system from the saved JSON.

Verifying that a change actually landed

show runningconfiguration all
sonic-cfggen -d --print-data
redis-cli -n 4 keys "VLAN|*"
redis-cli -n 4 hgetall "PORT|Ethernet0"

sonic-cfggen -d dumps the deployed configuration database — the authoritative view of what the switch believes. When the CLI accepts a command but traffic still does not pass, compare what you typed with what the DB holds; a rejected or mis-parsed field is common with complex values such as VLAN ranges.

Containers and services

show feature status
docker ps
docker exec -it bgp bash
systemctl status swss
systemctl restart bgp
sudo vtysh -c "show ip bgp summary"
sudo vtysh -c "show running-config"

Routing protocols in SONiC run inside FRR in the bgp container; the CLI you use for BGP runs inside that container. If show ip bgp summary returns nothing on the host, run it via docker exec or vtysh. show feature status is the fastest answer to "why is this feature not doing anything" — a feature that is disabled in the DB is disabled regardless of its configuration.

Logs and troubleshooting

show logging
tail -f /var/log/syslog
show techsupport
counterpoll show
show buffer_pool watermark
show queue counters
show priority-flow-control counters

show techsupport generates the bundle for vendor escalation. counterpoll show reveals the counter polling intervals — useful when counters look suspiciously static, because a long polling interval makes a busy link look idle. For congestion work, show buffer_pool watermark and show queue counters together tell you whether loss is ingress or egress and which queue holds microburst watermarks.

Platform and environment

show version
show platform summary
show platform temperature
show platform syseeprom
show environment
sudo sfputil show eeprom -p Ethernet0

Optic diagnostics matter more on SONiC because the platform is often a white-box with commodity optics: sfputil reads the EEPROM and DOM values directly. Use show environment to catch a fan or PSU warning before it becomes an ASIC over-temperature event.

A working order for new faults

1. show interfaces status — link state per port.
2. show interfaces counters errors — physical integrity.
3. show feature status and docker ps — is the relevant service even running?
4. sonic-cfggen -d — does the DB match your intent?
5. show logging / /var/log/syslog — the actual error message.

Compare with the site's SONiC CLI cheat sheet covering show, config and Docker commands and the data-model view in CONFIG_DB and JSON configuration.

The four SONiC gotchas

1. Unsaved changes. A change that works and then disappears after a reboot was never saved. sudo config save -y writes config_db.json; there is no implicit commit as in Junos.
2. Feature disabled in the database. A feature whose service is not enabled shows configured but inactive. show feature status is the arbiter, not the presence of configuration.
3. CLI accepted, database rejected. Complex values such as VLAN ranges or ACL selectors are interpreted by config commands and then validated against the schema. When a command succeeds without effect, dump the database with sonic-cfggen -d --print-data and look at what was actually stored.
4. Show command returns nothing. Routing state lives in the bgp container: run docker exec -it bgp vtysh -c "show ip bgp summary" rather than assuming the session is down.

Day-one configuration order

sudo config hostname leaf-01
sudo config interface ip add Ethernet0 10.0.0.1/31
sudo config interface startup Ethernet0
sudo config vlan add 10
sudo config interface vlan add Ethernet1 10
sudo config save -y
show interfaces status
show ip interfaces

Note config interface startup: an interface with an IP address but no startup entry stays down, which is one of the more common reasons a freshly provisioned SONiC port carries nothing.

原文链接：https://route2open.com/sonic-cheat-sheet