Configuration and Operational State

Ask whether a value describes intent, observed behavior, or the configuration a future boot will load.

Prerequisite: Databases and the Configuration-to-Forwarding PathLesson 04 · operator workflow

By the end, you should be able to:

Distinguish running configuration, runtime state, and saved startup configuration.
Use targeted read-only inspection to compare intent with behavior.
Recognize management interfaces that have different persistence rules.

Baseline: community SONiC 202505 release-branch source, pinned in the references; single ASIC, default namespace, community CLI. This is not a claim about the latest release or a certified vendor image. The Windows checkout was cross-checked separately. Commands are examples only; no device changes or live verification were performed.

Three views of the same port

Imagine a port configured administratively up but showing no carrier. The configuration can be correct while the link is down: the peer may be off or the cable absent. Keep these three views separate when diagnosing that difference.

View	Meaning	What it cannot establish
Running configuration	Intent in CONFIG_DB, such as the port’s administrative status.	That the link came up or dependent programming completed.
Operational / runtime state	What services, interfaces, and forwarding components currently report.	That this state will return after reboot.
Saved startup configuration	The file used by the normal boot configuration workflow, commonly `/etc/sonic/config_db.json` on this single-ASIC baseline.	That the file matches today’s running intent.

Intent, observation, and persistence

Original conceptual diagram. Service application can be asynchronous and feature-dependent. An explicit export to another filename creates a snapshot rather than changing the default startup file.

Read further: 202505 configuration manual (pinned).

Inspect intent, then observe the port

For a single-ASIC community image, start by recording identity and checking local help. Here Ethernet0 stands for an existing port discovered on the target; aliases and breakout layouts differ.

show version
show runningconfiguration ports --help
show runningconfiguration ports Ethernet0
show interfaces status Ethernet0

Read-only inspection examples for the selected baseline. Commands may require suitable privileges. Illustrative only; not executed on a SONiC device.

The port configuration view reads the PORT configuration table. A shortened, invented example might be:

{
  "admin_status": "up",
  "mtu": "9100"
}

Illustrative excerpt; other fields omitted. Illustrative only; not executed on a SONiC device.

If the status view reports Admin up / Oper down, do not “repair” that by saving configuration. Saving cannot create carrier. Investigate the peer, physical connection, compatible optics and speed, and platform evidence as appropriate. In a virtual environment, inspect the virtual topology instead.

Read further: 202505 show CLI implementation · 202505 interface inspection implementation.

Compare with the saved view

A targeted read of the startup file can answer a different question: what administrative value is saved for this port? The Linux command below reads JSON; it does not apply it.

sudo python3 -c 'import json; c=json.load(open("/etc/sonic/config_db.json")); print(c.get("PORT", {}).get("Ethernet0", {}).get("admin_status", "not set"))'

Read-only saved-file inspection. A missing value may mean a default or absent entry, not automatically “down”. Illustrative only; not executed on a SONiC device.

Suppose it prints down while the running port view says up. That shows a saved-versus-running difference for this field. It does not prove which value is intended. Record the difference, ask what the approved desired state is, and use the change workflow in lesson 06 before reconciling it.

Read further: 202505 configuration CLI implementation.

Stay within the management model

The examples use community show and config utilities. Vendor shells, REST/gNMI agents, and controller-managed images can introduce different validation and persistence behavior. Confirm their supported workflow rather than translating commands by name.

Likewise, a configuration changed directly inside FRR can have routing-mode-specific persistence rules. Do not assume a vtysh change becomes a CONFIG_DB entry. show runningconfiguration all on this baseline also gathers routing text; its output is not a promise of a clean, directly restorable CONFIG_DB dump.

Operator habit: write down the source, instance, and time for each observation. Configuration is one source of evidence. Database writes through arbitrary Redis commands bypass the supported workflow and are not a safe substitute for it.

Read further: 202505 show CLI implementation · 202505 command reference (pinned).

Key takeaways

Running intent, runtime observations, and startup files answer different questions.
Administrative up does not prove operational link up.
Normal CONFIG_DB changes do not automatically rewrite the startup JSON file.
Use the management model supported by the exact image and routing mode.

Check your understanding

Six questions, four choices each. Check each answer, review the explanation and score, and retry.

Sources & baseline

Reviewed 18 October 2026. Community 202505 branch snapshots: sonic-utilities 7511bf2f8ea3; sonic-buildimage ff3c0c9f686a. Confirm commands with local help and image support before using them. Historical prose within a release branch can describe older behavior; implementation was checked for the examples used here.

Additional read-only Windows source cross-check: sonic-buildimage 128f6802b6e1, sonic-utilities cc4fbb3e8313 (config/main.py, show/main.py, and show/interfaces/__init__.py). This different checkout supports the roles illustrated; it is not presented as a 202505 binary. Full paths, revisions, and verification limits are recorded in SOURCE-REVIEW.txt beside this page.