SONiC VLAN Configuration and Verification

2026年9月19日 LOG admin

SONiC keeps configuration in a Redis database rather than a text running-config, and the CLI is a thin wrapper over that database. Once you internalise that model, VLAN configuration stops being mysterious: the same objects are also visible in config_db.json, and knowing which of the two you edited explains most "my change disappeared" problems. This guide covers VLAN creation, member ports, verification, and the save/reload semantics that trip up engineers coming from IOS or EOS.

Create and delete VLANs

admin@sonic:~$ sudo config vlan add 10
admin@sonic:~$ sudo config vlan add -m 20,30
admin@sonic:~$ sudo config vlan add -m 50-60
admin@sonic:~$ sudo config vlan del 30

The -m flag accepts comma-separated lists and ranges, which is the difference between a one-line change and twenty commands on an access switch.

Add member ports: tagged vs untagged

On SONiC, a port is untagged in a VLAN by default; adding -u explicitly marks it untagged, while adding it without -u makes it tagged.

# Untagged (access) port
admin@sonic:~$ sudo config vlan member add 10 -u Ethernet1

# Tagged (trunk) member
admin@sonic:~$ sudo config vlan member add 20 Ethernet4

# Bulk operations
admin@sonic:~$ sudo config vlan member add 20 -m Ethernet5,Ether6
admin@sonic:~$ sudo config vlan member add 10 Ethernet1-Ether3
admin@sonic:~$ sudo config vlan member del 20 Ethernet4

Two rules cause most failed attempts. First, the VLAN must exist before you add members — create with config vlan add first. Second, a port configured as a router port cannot be a VLAN member; SONiC rejects the command rather than silently ignoring it.

Port channels as VLAN members

admin@sonic:~$ sudo config portchannel add PortChannel0004
admin@sonic:~$ sudo config portchannel member add PortChannel0004 Ethernet48
admin@sonic:~$ sudo config portchannel member add PortChannel0004 Ethernet49
admin@sonic:~$ sudo config vlan member add 10 PortChannel0004
admin@sonic:~$ sudo bridge vlan

Making the port-channel a tagged member is the standard way to carry server VLANs across a LAG.

Verification: three views of the same truth

admin@sonic:~$ show vlan brief
admin@sonic:~$ show vlan config
admin@sonic:~$ sudo bridge vlan
admin@sonic:~$ redis-cli -n 4 keys "VLAN|*"

Command	What it shows
show vlan brief	Live kernel/bridge view: VLAN id, IP address, member ports, tagging, proxy ARP, DHCP helper
show vlan config	Configured VLAN and member list from the VLAN table in Config DB
bridge vlan	Per-port PVIDs and tagged/untagged sets from the Linux bridge

When configuration and live state disagree, compare show vlan config with show vlan brief: the first is intent, the second is reality. A divergence usually means the orchestrator has not converged, or a direct edit was never loaded.

Save, reload and the config_db.json trap

# Persist what you just configured
admin@sonic:~$ sudo config save -y

# Load an edited config from disk (destructive to unsaved changes)
admin@sonic:~$ sudo config load -y
admin@sonic:~$ sudo config reload -y

The rule that matters: after CLI changes, run config save; after editing /etc/sonic/config_db.json by hand, run config reload rather than config save. A save after a manual edit overwrites your edit with the older running data; a reload after CLI changes throws away work you had not saved. Pick the one that matches how the change was made.

The VLAN table also carries DHCP relay configuration, so relay servers can be declared per VLAN inside config_db.json:

"VLAN": {
  "Vlan1000": {
    "vlanid": "1000",
    "members": ["Ethernet0", "Ethernet4"],
    "dhcp_servers": ["192.0.0.1", "192.0.0.2"]
  }
}

A short operational checklist

Create the VLAN, then add members, then verify with show vlan brief.
Confirm tagging intent — an accidental tagged member on a server access port looks like a dead link to the host.
config save -y and note the change in your source of truth (config_db.json in Git is the usual pattern).
For SVI addressing, remember the SVI is a separate object; a VLAN with no SVI will forward but not route.

Treat Config DB as the source of truth and the CLI as a convenience, and SONiC behaviour becomes predictable instead of surprising.