Command Reference
Organized by purpose, with a layer, a safe/disruptive indicator, and an open-source vs vendor-specific label. Example output is illustrative — verify against your image.
54 commands
Display SONiC image version, build date, platform, HwSKU, ASIC vendor, and uptime.
show versionSONiC Software Version: SONiC.<branch>-<build>
Distribution: Debian <n>
Kernel: <ver>
Platform: <platform>
HwSKU: <hwsku>
ASIC: <vendor>
Uptime: ...Interpretation: Anchor every observation to this version and distribution — CLI, DB layout, and defaults vary across releases.
Illustrative output; exact fields vary by image.
Show platform identifier, HwSKU, and ASIC/switch type where available.
show platform summaryOn SONiC-VS the platform is virtual and does not reproduce real ASIC behavior.
Read the system EEPROM (serial, base MAC, model) via the platform API.
show platform syseepromFields depend on the platform's ONIE TLV EEPROM; not present on VS.
List SONiC features and whether each is enabled, plus auto-restart policy.
show feature statusInterpretation: A missing container in `docker ps` is often just a disabled feature here, not a failure.
Show per-port admin/oper state, speed, MTU, alias, and lane mapping.
show interfaces statusInterpretation: Oper 'up' confirms link, not end-to-end forwarding — that still depends on FIB/FDB programming.
List L3 interfaces with assigned IPs, admin/oper state, and VRF binding.
show ip interfacesAdministratively disable a port (and `startup` to re-enable it).
sudo config interface shutdown Ethernet0Disruptive: drops link and traffic on the port. Confirm the target interface before running.
Read optic/DOM data (presence, type, DOM thresholds) for a transceiver.
show interfaces transceiver eeprom Ethernet0Populated by pmon; unavailable on VS. Field set varies by module and platform.
Show configured VLANs with member ports, tagging mode, and VLAN IPs.
show vlan briefCreate a VLAN in CONFIG_DB (members added with `config vlan member add`).
sudo config vlan add 100Non-disruptive to create, but changing membership on live ports can affect traffic.
Display the learned FDB (MAC table): MAC, VLAN, port/tunnel, and type.
show macInterpretation: In EVPN VXLAN, remote MACs point at a VTEP tunnel rather than a local port.
Show the IPv4 routing table as seen by the SONiC CLI (sourced from FRR/zebra).
show ip routeInterpretation: This is the control-plane RIB view. A route here is not proof it is programmed in the ASIC FIB.
Query FRR directly for the RIB, including protocol source and selected best paths.
vtysh -c 'show ip route'Codes: K - kernel, C - connected, S - static, B - BGP, O - OSPF ...
B>* 10.0.0.0/24 [20/0] via 192.0.2.1, Ethernet4, ...Interpretation: '>' marks the selected route, '*' FIB-installed (in the kernel). Confirm hardware separately via ASIC_DB/data-plane test.
Illustrative output; exact fields vary by FRR version.
Add a static route into CONFIG_DB, which FRR/staticd then resolves.
sudo config route add prefix 10.9.0.0/24 nexthop 192.0.2.1Command form varies by version; verify with `config route --help` on your image.
Show FRR's running configuration (zebra/bgpd/etc.) as FRR sees it.
vtysh -c 'show running-config'Interpretation: SONiC may render FRR config from CONFIG_DB (templated) or use frr.conf (split mode) — know which your image uses.
Summarize BGP neighbors, session state, uptime, and prefix counts.
show ip bgp summaryNeighbor V AS MsgRcvd MsgSent Up/Down State/PfxRcd
192.0.2.1 4 65001 ... ... 00:12:31 42Interpretation: A numeric PfxRcd means Established; a state word (Idle/Active/Connect) means the session is not up.
Illustrative output; exact columns vary by FRR version.
Inspect a single BGP peer: capabilities, timers, counters, and last error.
vtysh -c 'show bgp neighbor 192.0.2.1'Interpretation: Use the 'Last reset' reason and negotiated capabilities to diagnose flaps and address-family mismatches.
Reset BGP sessions to force re-negotiation/re-advertisement.
vtysh -c 'clear bgp *'Interpretation: Prefer a soft clear (`clear bgp * soft`) to avoid tearing sessions down.
Disruptive: a hard clear drops sessions and can cause a transient traffic/route withdrawal. Use soft clear where possible.
Render the BGP portion of the running configuration from SONiC.
show runningconfiguration bgpShow EVPN address-family neighbors and their EVPN prefix counts.
vtysh -c 'show bgp l2vpn evpn summary'Interpretation: Confirms the l2vpn evpn AFI/SAFI is negotiated; a missing peer here means EVPN is not exchanging routes even if IPv4 unicast is up.
List received/advertised EVPN routes (Type-2 MAC/IP, Type-3 IMET, Type-5 prefix).
vtysh -c 'show bgp l2vpn evpn route'Interpretation: Type-2 carries MAC/IP bindings, Type-3 multicast/flood, Type-5 routed IP prefixes for symmetric IRB.
Show EVPN VNIs known to FRR, their type (L2/L3), VRF, and local VTEP IP.
vtysh -c 'show evpn vni'Interpretation: L3 VNI maps to a VRF for symmetric IRB; L2 VNI maps to a bridge domain/VLAN.
Show configured VXLAN tunnel endpoints (VTEP source and remote IPs).
show vxlan tunnelDisplay the VLAN-to-VNI mappings that bind L2 domains to overlay segments.
show vxlan vlanvnimapList remote VNIs learned per remote VTEP (control-plane learned reachability).
show vxlan remotevni allAvailability and exact subcommands vary by SONiC version.
Show remote MACs learned over VXLAN and the VTEP/tunnel they resolve to.
show vxlan remotemac allInterpretation: Correlate with `show mac` and EVPN Type-2 routes to trace L2 reachability end to end.
Show VNET (VXLAN-based L3 tenant) routes where the VNET model is used.
show vnet routes allVNET is an alternative overlay model to EVPN; presence and semantics depend on the image/deployment.
List running SONiC feature containers.
docker psInterpretation: Each feature is a container; a missing one may be a disabled or failed feature.
Enter the FRR shell inside the bgp container for interactive routing queries.
docker exec -it bgp vtyshInterpretation: Equivalent to `vtysh` on the host when the CLI wrapper is available; useful when it is not.
Restart the SWSS service/container (orchagents).
sudo systemctl restart swssInterpretation: Restarting swss cascades to dependent services (syncd) and, without warm restart, disrupts forwarding.
Disruptive: unless warm restart is configured and supported, this can flush hardware state and drop traffic.
Query a named SONiC DB by name via the version-aware sonic-db-cli wrapper.
sonic-db-cli CONFIG_DB KEYS 'PORT|*'Interpretation: Prefer sonic-db-cli (resolves DB name→number from database_config.json) over hardcoding `-n <num>`, which drifts across versions.
For large keyspaces prefer SCAN over KEYS; on this pattern the match is narrow, but avoid `KEYS *`.
Safely enumerate route entries in APPL_DB without a blocking full scan.
sonic-db-cli APPL_DB SCAN 0 MATCH 'ROUTE_TABLE:*' COUNT 100Interpretation: Prefer SCAN or targeted keys over `KEYS *`, which can stall the single-threaded Redis server at scale. SCAN returns a cursor to iterate.
Presence in APPL_DB means submitted to orchestration, not yet programmed in hardware.
Read all fields of a specific hash key (here, observed port state).
sonic-db-cli STATE_DB HGETALL 'PORT_TABLE|Ethernet0'Interpretation: Targeting one key is the fastest, safest read — no scan needed when you already know the key.
Enumerate SAI route objects that syncd has pushed toward hardware.
sonic-db-cli ASIC_DB SCAN 0 MATCH 'ASIC_STATE:SAI_OBJECT_TYPE_ROUTE_ENTRY:*' COUNT 100Interpretation: Presence here means syncd issued the SAI op — it is the DB representation of the programmed object, not the silicon itself. Confirm forwarding with counters or a data-plane test.
Never use `KEYS *` on ASIC_DB in production; it can be very large. Use SCAN with a specific type prefix.
Show aggregated SONiC syslog (typically /var/log/syslog) via the CLI.
show loggingRead systemd journal for a specific service window.
journalctl -u swss --since '-15 min'Read stdout/stderr logs from a specific feature container (e.g. syncd SAI errors).
docker logs --tail 100 syncdInterpretation: syncd logs are where SAI/SDK programming errors surface; correlate timestamps with config changes.
Dump the SAI object view that syncd holds, for deep ASIC-programming inspection.
docker exec -it syncd saidumpInterpretation: Reflects the SAI object database (what was programmed via SAI), not a live register read of the silicon. Availability varies by vendor syncd build.
Read-only, but can be large/CPU-heavy on scaled systems; run with care in production.
Show NPU/ASIC-related platform details where the image exposes them.
show platform npuSubcommand set is platform- and version-dependent; verify with `show platform --help`.
Show per-port RX/TX packet, byte, error, and discard counters.
show interfaces countersInterpretation: Values are polled snapshots (flexcounter), not per-packet live reads — brief microbursts may be under-represented. Use `-p <sec>` for rate over an interval.
Show per-queue counters (unicast/multicast, drops) for QoS/congestion analysis.
show queue counters Ethernet0Queue model and counter availability are ASIC-dependent.
Show configurable drop counters to attribute drops to specific reasons.
show dropcounters countsInterpretation: Debug drop counters must usually be initialized/configured; supported reasons vary by ASIC.
Show the Linux kernel FIB — a third route view distinct from FRR RIB and ASIC FIB.
ip route showInterpretation: FRR installs selected routes into the kernel; SONiC mirrors kernel/FRR state to hardware. Kernel and ASIC can disagree during faults.
Show kernel netdev link state for front-panel and internal interfaces.
ip -br link showList failed systemd units — an early signal a subsystem is down.
sudo systemctl --failedCollect a comprehensive support bundle (logs, DB dumps, config, state) into an archive.
sudo show techsupportInterpretation: The go-to first capture for escalations; snapshots state across all layers at once.
Non-disruptive but I/O- and CPU-intensive and can take minutes on scaled systems; use `--since` to bound it.
Show the ARP/neighbor table used to resolve next-hops to MACs.
show arpInterpretation: Unresolved neighbors are a common reason a RIB route never becomes a programmed next-hop.
Reload CONFIG_DB from config_db.json, restarting dependent services to reapply intent.
sudo config reload -yInterpretation: Used to recover from drift, but it restarts services and reprograms hardware.
Disruptive: restarts services and can interrupt forwarding. Not a routine command — use in a maintenance window.
Persist CONFIG_DB to /etc/sonic/config_db.json so it survives reboot.
sudo config save -yInterpretation: Non-disruptive, but forgetting it means config is lost on the next reboot.
Render the full running configuration (CONFIG_DB plus FRR) as JSON.
show runningconfiguration allWrite the current CONFIG_DB to an explicit backup file for archival/rollback.
sudo config save /home/admin/backup_config_db.jsonMulti-ASIC platforms use per-namespace config files; verify the expected path on your platform.
Access the Broadcom diagnostic shell for low-level ASIC inspection on Broadcom-based platforms.
docker exec -it syncd bcmcmd '<diagnostic>'Interpretation: Bypasses the SAI abstraction to read vendor SDK state directly; only meaningful on Broadcom silicon and only where the build exposes it.
Vendor-specific and image-dependent — exact entrypoint, availability, and subcommands must be verified against Broadcom/platform documentation. Some diagnostic subcommands can be disruptive; treat as expert-only. Do not assume this syntax is authoritative.
Collect a vendor-enhanced diagnostic bundle on an enterprise SONiC distribution (e.g. Dell Enterprise SONiC).
<enterprise SONiC 'show tech-support' equivalent>Interpretation: Enterprise distributions add commands and bundles beyond upstream; the exact command and contents differ per vendor.
Vendor-specific: command name and behavior vary by distribution/version. Verify against the vendor's documentation rather than assuming this placeholder syntax.
Use an enterprise management framework (klish CLI, gNMI, or REST) offered by a commercial SONiC distribution.
<vendor management-framework / gNMI / REST call>Interpretation: Enterprise SONiC often layers an industry-standard CLI/management framework and YANG-modeled APIs over upstream SONiC.
Vendor-specific and version-dependent — model coverage, transport, and syntax must be confirmed against the vendor's documentation. Placeholder shown; not authoritative.