SONiC CLI Mastery: Config Commands and Show Monitoring

2026年8月24日 LOG admin

SONiC, the open-source network operating system developed by Microsoft and donated to the Open Compute Project, is managed primarily through a Linux-based CLI that feels familiar to anyone who has used a shell. This guide takes you from the first SSH login through management interface configuration, AAA/TACACS+ integration, ACL creation, and static ARP entries, then covers the show commands that give you real-time visibility into uptime, reboot causes, environmentals and interface status. It is a practical foundation for running SONiC in production data centers.

Logging In and Configuring the Management Interface

sudo config interface ip add Ethernet0 192.0.2.10/24

Use help or ? at any prompt for command assistance.

Two things catch people out on their first login. First, the admin account has sudo rights but the CLI itself is not a vendor-style “enable/configure” hierarchy — you run sudo config ... at a bash prompt, and the SONiC tools translate that into changes in the underlying database. Second, there are two different naming worlds: the Linux management interface is eth0, while the front-panel ports are Ethernet0, Ethernet4 and so on, numbered in steps of four to match the hardware lanes. If a command reports that an interface does not exist, you are almost always using a name from the wrong world.

What the CLI Actually Changes: config_db.json

Every config command writes into CONFIG_DB, a Redis database backed by the file /etc/sonic/config_db.json. The switch loads that JSON at boot, so configuration you change from the CLI is only persistent once the database is saved to disk:

sudo config save -y
ls -l /etc/sonic/config_db.json
sudo config load -y
sudo config reload -y

config save merges the running configuration into config_db.json, creating a timestamped backup of the previous file. config load pushes the file back into the databases without restarting services, while config reload clears everything and reapplies config_db.json — useful when you have made a change that did not take effect, and dangerous for the same reason. Because SONiC stores configuration in a JSON database (config_db.json), the CLI commands above are the safe, supported way to change it. Editing the JSON by hand works, but a typo gives you a switch with missing configuration after the next reload rather than an error message.

Configuring AAA and TACACS+

sudo config aaa authentication login tacacs+ local
sudo config tacacs add 10.0.0.1

The first command makes TACACS+ the primary authentication method with the local database as fallback; the second registers the TACACS+ server. In practice you will also want to record the shared key and a timeout, so the switch fails over to local authentication quickly instead of hanging while it waits for an unreachable server:

sudo config tacacs add 10.0.0.1 --timeout 5 --key MySharedSecret
sudo config tacacs delete 10.0.0.1
show tacacs

Test with a fresh SSH session before you close the one you are holding. The most common SONiC AAA incident is a TACACS+ server that has been added but whose key does not match, which locks out remote logins until someone with console access fixes it.

ACL and Static ARP Configuration

sudo config acl add table MyAclTable L3
sudo config acl add rule MyAclTable 10 --src-ip 192.0.2.0/24 --action forward
sudo config arp add 192.0.2.1 00:0a:95:9d:68:16

An ACL in SONiC is a table plus rules. The table declares where the ACL lives and which ASIC stage it uses, and the rules are matched in ascending order of rule ID. Extending the example to something you would actually deploy looks like this:

sudo config acl add table EdgeFilter L3 --stage ingress
sudo config acl add rule EdgeFilter 100 --src-ip 192.0.2.0/24 --dst-ip 198.51.100.10/32 --action forward
sudo config acl add rule EdgeFilter 200 --ip-protocol 17 --dst-port 161 --action drop
sudo config acl remove rule EdgeFilter 200
show acl table
show acl rule

A drop rule with an explicit deny is far easier to debug than a filter that silently removes traffic, and show acl rule confirms that the rule you wrote is the rule the ASIC received. Static ARP entries complement the same workflow: they pin an important gateway or next hop to a known MAC address, which protects a critical path from ARP spoofing and removes ARP resolution delay for a heavily used neighbour. Removing one is the same command with delete, and show arp lists resolved entries alongside the static ones.

VLANs and Link Aggregation

Two more flows you will need within the first hour of a deployment. VLANs are created and then populated with members, and the untagged flag controls whether the port sends frames with a tag:

sudo config vlan add 100
sudo config vlan member add 100 Ethernet0 --untagged
sudo config vlan member add 100 Ethernet4
show vlan brief

Link aggregation follows the same create-then-add-members pattern, and should match the switch at the far end:

sudo config portchannel add PortChannel0001
sudo config portchannel member add PortChannel0001 Ethernet0
sudo config portchannel member add PortChannel0001 Ethernet4
show interfaces portchannel
show lacp neighbor

Because a LAG hides a failed member behind a healthy aggregate, always verify that the member count is what you expect. show lacp neighbor confirms both ends agree on the aggregate, which is the fastest way to find a mismatched LACP mode.

Interface Startup, MTU and Breakout

sudo config interface startup Ethernet0
sudo config interface shutdown Ethernet0
sudo config interface mtu Ethernet0 9000
sudo config interface breakout Ethernet0 4x25G[10G]

Breakout splits a high-speed port into several lower-speed ports, and it rewrites the interface naming on the running system — do it before you build a configuration that depends on port names, not after. MTU, by contrast, must be consistent end to end; raising it on SONiC while the rest of the fabric stays at 1500 turns a working path into a black hole for large frames.

Monitoring with Show Commands

show system uptime
show reboot-cause
show environment
show interface status
show ip bgp summary
show runningconfiguration all

show reboot-cause explains why the switch rebooted, show environment reports temperature, fan speed and power supply status, and interface status output verifies link and speed per port. The set is worth memorising in full because most incidents start with “when did it change?”:

show version
show platform summary
show interface counters
show ip route
show arp
show mac
show lldp neighbors
show logging
show techsupport

show version gives the SONiC release and the platform, show platform summary identifies the ASIC, show interface counters exposes discards and errors that a link-state check will never show you, and show lldp neighbors proves which physical port is patched into which other switch. show techsupport produces the bundle that support teams ask for, and it is much easier to run it while the fault is live than to reconstruct it afterwards.

BGP and the FRR Layer

SONiC delegates routing protocols to FRR, so routing is configured through FRR rather than through config commands, and monitored through the same show commands:

show ip bgp summary
vtysh -c "show ip bgp summary"
vtysh -c "show ip route"

Persistent FRR configuration lives under /etc/sonic/frr/, and vtysh gives you the familiar Cisco-style interface for anything the show wrappers do not cover.

A Worked Example: Adding a VLAN End to End

Pulling the individual commands into one sequence shows how the pieces fit together. Suppose you are adding a new server segment on VLAN 200, aggregated across two ports, and you want it to be persistent:

sudo config vlan add 200
sudo config vlan member add 200 Ethernet8 --untagged
sudo config vlan member add 200 Ethernet12 --untagged
sudo config interface ip add Vlan200 192.0.2.1/24
sudo config save -y
show vlan brief
show interface status
show ip route

The VLAN must exist before a member can be added to it, and the Layer 3 interface Vlan200 is created implicitly by assigning an address — the SVI only becomes operationally up when at least one member port is up, which is why show vlan brief and show interface status belong in the same breath. Until the change is saved, it survives only until the next reload.

Backups and Rolling Back

config save keeps a copy of the previous configuration, so an unwanted change is usually recoverable without a console cable. Find the backup, review the difference, and load the version you want:

ls -l /etc/sonic/old_config/
sudo config load /etc/sonic/old_config/<backup_file> -y

Read the file before you load it. Restoring a backup also restores every other change that was made in the meantime, which is occasionally exactly what you want and more often what turns a small mistake into an outage.

When the CLI and the Data Plane Disagree

SONiC is a set of containerised processes, and that is a feature when you are troubleshooting: the CLI, the database and the ASIC can be inspected separately. If a configuration looks right but traffic does not flow, work down the stack:

sudo docker ps
sonic-db-cli CONFIG_DB keys '*' | head
sonic-db-cli APPL_DB keys '*' | head
show logging
sudo systemctl status swss
sudo systemctl status syncd

CONFIG_DB is what you asked for, APPL_DB is what the software prepared for the ASIC, and ASIC_DB is what the hardware was actually programmed with. When a change is present in CONFIG_DB but missing further down, one of the SONiC services was not running or did not react — restarting the relevant container is the recovery step, and the log is where the reason lives.

The Same CLI, Different Vendors

SONiC's CLI is deliberately close to Cisco and Arista conventions, but the differences matter when you move between a reference switch and a vendor image. The command families behave the same — config interface, config vlan, config acl, show ip bgp summary — while the plumbing underneath is different in three ways worth remembering:

Everything is a database write. On a traditional NOS, config edits the running configuration and you save it later. In SONiC the command writes into CONFIG_DB and services react. That is why a command can succeed and still not take effect: check the database, not just the exit code.
Not every knob is wrapped. If there is no CLI verb for the feature you need, the escape hatch is sonic-db-cli or editing config_db.json directly — supported for some tables, risky for others. Which tables are safe to touch is covered in config_db.json: save, reload and replace safely.
Vendor images add extensions. Platform-specific commands sit outside the community CLI, and a script written against one vendor's image may fail on another even though the community commands match. Keep vendor extensions out of portable scripts.

For the mode structure behind this — which commands need sudo, which need the sonic-cli wrapper, and how the two trees differ — SONiC CLI commands: show, config and sonic-cli modes is the companion read, and the management-VRF specifics are in the management command cheat sheet.

Driving the CLI from Scripts and Batch Provisioning

Because the CLI is a wrapper over a database and a container stack, it behaves well under automation — but only if the script checks state rather than trusting each command's return code. A minimal provisioning loop for a rack of switches looks like this:

for host in sw01 sw02 sw03 sw04; do
  ssh admin@$host 'sudo config save -y && sudo config vlan add 100 && \
    sudo config vlan member add 100 Ethernet0 && \
    sudo config interface startup Ethernet0 && \
    show vlan brief'
done

Three habits keep a script like this safe. First, run config save before making changes as well as after, so a failed run leaves a known-good backup. Second, print the resulting state and grep it in the script — an exit code of zero from config does not prove the ASIC was programmed. Third, deploy to one switch, verify traffic, then widen; a batch loop that fails halfway leaves a rack in mixed configuration, which is the hardest state to reason about. When something does misbehave in that state, SONiC troubleshooting for packet drops and link issues and the Supermicro SONiC configuration walkthrough cover the platform-specific checks.

原文链接：https://stordis.com/mastering-the-community-sonic-command-line-interface-a-comprehensive-guide/

作者：admin

链接：https://gitgit.ee/sonic-cli-configuration-guide.html

文章版权归作者所有，未经允许请勿转载。