SONiC OS CLI Cheat Sheet: 50 Essential Commands

SONiC (Software for Open Networking in the Cloud) is the open-source network OS used across Microsoft Azure and a growing list of data center operators, but its CLI is unlike IOS or Junos — it is built on Linux tools, Redis-backed configuration databases, and a Klish-based management shell. If you are new to SONiC, the first hurdle is simply knowing which command to type. This cheat sheet collects the commands you will actually reach for, grouped by task, covering system and platform checks, interface and VLAN configuration, port-channels, BGP and routing, ACL and QoS verification, management settings, configuration persistence, container-level debugging and troubleshooting. Keep it open in a second window during your first weeks on a SONiC box.

How to Read This Cheat Sheet

Three conventions apply throughout. First, configuration commands are usually run through sudo because they write into the Redis config database owned by root, so you will see sudo config ... far more often than the bare command. Second, show commands are read-only and safe on a production switch at any time — they read state from the ASIC, the kernel or a container and change nothing. Third, subcommands can generally be abbreviated to their first three letters, so show int status is accepted as show interfaces status.

Nothing you type with config survives a reboot until you explicitly save it. That one rule causes more confusion than any other part of SONiC, and it is covered in the Save and Reload section below.

System, Platform and Version Commands

show version
show hostname
show uptime
show platform summary
show platform syseeprom
show system health
show environment
show reboot-cause
show memory
show processes cpu
sonic-installer list

show version prints both the SONiC build and, importantly, the platform and ASIC identifiers — the first thing to capture when you file a support case. show platform summary confirms the hardware SKU matches the image you installed, and show reboot-cause tells you why the switch restarted last, which is invaluable when a device reboots during the night and nobody admits to a power event.

Interface and Port Commands

show interfaces status
show interfaces counters
show interfaces counters -a
show interfaces description
show interface Ethernet0
show interface Ethernet0 flap
show interfaces transceiver presence
show interfaces transceiver eeprom Ethernet0 --dom

sudo config interface ip add Ethernet0 10.0.0.1/24
sudo config interface ip remove Ethernet0 10.0.0.1/24
sudo config interface startup Ethernet0
sudo config interface shutdown Ethernet0
sudo config interface speed Ethernet0 100000
sudo config interface description Ethernet0 uplink-to-spine1
sudo config interface mtu Ethernet0 9216

The distinction between show interfaces counters and show interfaces counters -a matters: the plain form shows only non-zero counters in some builds, while -a shows all of them, which is what you want when you are checking whether an error counter is genuinely at zero. show interface Ethernet0 flap reveals whether a link has been bouncing — a port that looks fine right now can still have flapped forty times overnight.

VLAN and Layer 2 Commands

show vlan brief
show vlan 10
show mac
show mac -v 10
show lldp neighbors
show lldp table

sudo config vlan add 10
sudo config vlan del 10
sudo config vlan member add 10 Ethernet4
sudo config vlan member del 10 Ethernet4
sudo config vlan member add 10 Ethernet4 -u
sudo config save -y

The -u flag on config vlan member add creates the member as untagged, which is how you build an access port; without it the member is a tagged trunk port. show mac is the SONiC equivalent of a MAC address table dump and, combined with show lldp neighbors, gives you a two-command answer to "which switch and port is this host behind?"

Port-Channel and Link Aggregation Commands

show portchannel summary
show interfaces portchannel
show lacp port-channel
show lacp interface Ethernet8

sudo config portchannel add PortChannel1
sudo config portchannel del PortChannel1
sudo config portchannel member add PortChannel1 Ethernet8
sudo config portchannel member del PortChannel1 Ethernet8

A port-channel only comes up when the member links are up, correctly speed-matched and in the same VLAN membership; show lacp port-channel distinguishes "no member links up" from "LACP negotiation failed on one member", which is the difference between checking cables and checking configuration.

Routing, BGP and Neighbour Commands

show ip route
show ip route 10.0.0.0/8
show ipv6 route
show arp
show ndp
show bgp summary
show ip bgp summary
show bgp neighbors
show bgp neighbors 10.0.0.2 advertised-routes
show ip prefix-list
show route-map

sudo config bgp add-neighbor 10.0.0.2
sudo config bgp del-neighbor 10.0.0.2
sudo config bgp shutdown neighbor SONIC02SPINE
sudo config bgp shutdown all
sudo config bgp startup all

show ip bgp summary is the single most-used read command in a SONiC fabric: the state column shows whether each peer is Established, and the prefix counters show whether you are receiving the number of routes you expect. The config bgp shutdown pair is the graceful way to drain a switch out of service without touching cables — the sessions are withdrawn from the remote side, traffic reconverges, and you keep console access.

ACL, QoS and Buffer Commands

show acl table
show acl rule
show queue counters
show queue watermark
show pfc counters
show pfcwd stats
show buffer_pool watermark
show watermarks

sudo config acl add table MyTable L3
sudo config acl add rule MyTable MyRule -p 10 -a forward -s 10.0.0.0/8

Queue watermarks and PFC counters are how you prove a congestion problem rather than guess at one: a persistently high watermark on one queue means a single traffic class is saturating a port, and PFC pause counters tell you whether the lossless fabric is back-pressuring upstream. If the PFC counters are climbing alarmingly, read our SONiC PFC watchdog guide before the storm spreads.

Management, NTP and User Commands

show ntp
show ntpstatus
show dns
show clock
show management_interface address
show users
show runningconfiguration all

sudo config ntp add 192.168.1.1
sudo config ntp del 192.168.1.1
sudo config hostname dc-leaf-01
sudo config password admin
sudo config save -y

Time synchronisation deserves more respect than it usually gets on a switch: BGP session timers, syslog correlation and telemetry timestamps all depend on it, and an unsynchronised clock turns incident reconstruction into a guessing game. Configure at least two NTP servers and verify with show ntp that at least one is reachable and designated as the current source.

Save, Load, Reload and Upgrade

config save -y
config load /etc/sonic/config_db.json
config load -y /etc/sonic/config_db.json
config reload -y
config load_minigraph
config replace /etc/sonic/config_db.json
config bgp startup all
config interface startup all

config save -y writes the running configuration to /etc/sonic/config_db.json — always run it after changes, because SONiC does not auto-persist and a reboot silently discards anything unsaved. config reload -y rebuilds the state from that file and restarts almost every container, interrupting traffic for tens of seconds, so it belongs in a maintenance window. config replace takes a full config file and applies it as a diff rather than doing a restart. The subtleties of choosing between save, load, reload and replace are covered in depth in our config_db.json workflow guide.

Linux-Level and Container Commands You Will Actually Use

docker ps
docker exec -it bgp sh
docker exec -it swss sh
docker exec -it syncd sh
show services
sonic-cfggen -d --print-data
sonic-cfggen -H -k x86_64-mlnx_msn2700 --print-data
redis-cli -n 4 keys '*'
redis-cli -n 4 hgetall 'VLAN|Vlan10'
redis-cli -n 4 get 'DEVICE_METADATA|localhost'
show int status | grep Eth | wc -l

SONiC runs its services in containers — bgp, swss, syncd, pmon, teamd, database — and docker exec is how you get a shell inside them when you need to read a daemon's own configuration file or run its native tooling. Redis database instance 4 holds the configuration tables, so redis-cli -n 4 keys '*' is effectively a schema dump of everything the switch believes. Because SONiC's CLI is a Linux shell, ordinary pipelines work: the last example counts live ports, which is a one-liner that has no equivalent in IOS.

Troubleshooting and Support Commands

show logging
show logging -f
show interface Ethernet0 counters
show watermarks
show queue counters
show pfc counters
show buffer_pool watermark
show memory
show processes cpu
show platform
show platform syseeprom
show reboot-cause
show techsupport
sonic-installer list

Run show techsupport before a reload or a troubleshooting reboot, not after — it captures the state you are about to destroy, packaged as a tarball that vendor support will ask for anyway. For a structured diagnostic order rather than a command list, work through our SONiC packet drop and link troubleshooting guide and SONiC drops, optics and techsupport reference.

Handy One-Liners and Pipe Tricks

Because the SONiC shell is bash rather than a locked-down CLI, ordinary Unix pipelines answer questions that would require a script on a vendor NOS. These come up constantly during a change window:

show interfaces status | grep -c ' up '
show interfaces status | grep -iE 'Ethernet[0-9]+' | wc -l
show interfaces counters | awk '$6 > 0'
show ip route | grep -c '^B'
sonic-cfggen -d --print-data | grep -A2 MGMT_INTERFACE

The first counts live ports, which is how you confirm that a full rack of cabling actually came up after a maintenance window. The second counts configured ports, so you can tell the difference between "the ports are down" and "the ports were never created". The third filters the counter table down to interfaces with a non-zero receive error count, turning a wall of numbers into a short list of suspects. The fourth counts BGP-learned routes, a fast sanity check that the switch is receiving the table you expect.

Two cautions apply. Pipe output is best-effort text, so a vendor build that renames a column will silently break your grep — verify any one-liner by hand once before you build a monitoring check on top of it. And never wrap a pipeline around a config command in a way that auto-answers its prompts: the interactive confirmations exist to stop you wiping a live configuration by accident.

Quick Reference Table

More SONiC reading on this site: SONiC quick start: install via ONIE, SONiC user manual: install and configure, and SONiC management VRF and database commands.

原文链接：https://github.com/sonic-net/SONiC/wiki