Tagged VLAN Links

Extend one VLAN across an explicit tagged link and verify both ends of the membership contract.

Lesson 10 of 18Prerequisite: core lessons 01–09 or equivalent operator knowledge

By the end, you should be able to:

Separate endpoint untagged membership from inter-switch tagging.
Inspect both ends before interpreting learned MACs.
Repair and remove one isolated trunk membership.

Scope: community SONiC 202505 source baseline; single ASIC/default namespace unless stated. Commands, outputs, faults, and recovery are illustrative only. Confirm image, management mode, and platform support before a separate lab. No device commands, builds, containers, or packet tests were executed for this course.

One VLAN across two switches

Original topology. E0/E4 mean Ethernet0/Ethernet4; S1 E4 connects only to S2 E4. No second bridge link, SVI, or routing hop exists.

Scenario and baseline

Two independent switches join the same VLAN across one physical link. Linux endpoints are already configured as shown, links up, untagged, and use no gateway for their same-subnet exchange. On both switches, Ethernet0 and Ethernet4 begin admin-down, have no IP address or VLAN/LAG membership, and VLAN100 is absent. Management uses independent ports. There is no alternate bridge path or loop.

The access-side frames are untagged; the inter-switch frames carry VLAN100. A matching VLAN ID alone is insufficient: both egress tagging and ingress membership must agree.

Configure both ends

# Run separately on S1 and S2
show vlan config
config vlan member add --help
sudo config vlan add 100
sudo config vlan member add -u 100 Ethernet0
sudo config vlan member add 100 Ethernet4
sudo config interface startup Ethernet0
sudo config interface startup Ethernet4

The omitted -u on Ethernet4 deliberately selects tagged membership in the pinned CLI. This is one explicit VLAN on a link, not a promise that every VLAN is automatically allowed. No IP address belongs on these bridge member ports.

Inspect the bridge and packet boundary

# On both switches
show vlan config
show interfaces status Ethernet4
show mac -v 100
# On Host A only
ping -c 3 192.0.2.20

S1: Vlan100  Ethernet0 untagged; Ethernet4 tagged
S2: Vlan100  Ethernet0 untagged; Ethernet4 tagged
S1 FDB: B-MAC → Ethernet4
S2 FDB: A-MAC → Ethernet4

Illustrative shortened output, not a device observation.

After both hosts transmit, local sources should learn on the access port and remote sources on the inter-switch port. Before learning, unknown unicast can flood eligible VLAN100 members; ARP is broadcast, not unknown unicast. A permitted capture on the inter-switch link should show the tag, subject to capture/offload behavior. The FDB is software-visible evidence, not an independent ASIC dump.

Fault, repair, and cleanup

# S2 only: remove the trunk membership
sudo config vlan member del 100 Ethernet4
show vlan config
# Repair on S2
sudo config vlan member add 100 Ethernet4

Access links can remain up while ARP/traffic between the hosts fails after convergence. Do not blame endpoint masks until comparing both switch memberships. Stale FDB and host ARP entries may persist.

# Teardown, separately on BOTH switches after repair
sudo config vlan member del 100 Ethernet4
sudo config vlan member del 100 Ethernet0
sudo config vlan del 100
sudo config interface shutdown Ethernet0
sudo config interface shutdown Ethernet4
show vlan config

Repeat the bounded endpoint exchange before teardown; then compare the absent-VLAN/admin-down baseline. Do not save temporary running configuration.

Key takeaways

Tag behavior is a contract at both link ends.
Bridge membership does not imply routed addressing.
Remote source MACs learn toward the inter-switch link.
ARP broadcast and unknown-unicast flooding are distinct cases.

Check your understanding

Six questions, four options each. Check each answer for an explanation, review your score, and retry.

Sources & scope

Reviewed 18 October 2026. Community release-source pins: utilities 7511bf2f8ea3582c2b67cf5016f8e8237e62882b; buildimage ff3c0c9f686a1d0dbddbe813b233b3b7a51bd8e2. FRR 10.2 and RFC references explain semantics; they do not identify an installed image’s exact daemon version. Windows reference code is separately pinned: SWSS b8a9b65494c234ac33b6cf0a2b7f13fb291cee7f, buildimage 128f6802b6e1, utilities cc4fbb3e8313, SAI Redis dd925f4cf6fa. These are source-inspection baselines, not deployed-binary or hardware validation.

Exact inspected files and actual website checks are recorded in SOURCE-REVIEW.txt. No vendor CLI extension, production support level, scale, or timing guarantee is implied.