Ethernet Bridging, MAC Learning & VLANs

An Ethernet bridge joins MAC-service segments without requiring endpoints to announce routes. It learns where sources appear, then forwards frames toward destinations. This makes a switch easy to insert, but it also creates ageable hidden state, controlled flooding, and a strict need to prevent forwarding loops.

A VLAN is a forwarding context, not just four bytes in a frame. The bridge must first classify an ingress frame into that context, learn and look up state within it, and then decide whether the egress representation is tagged or untagged.

Bridge, repeater, and router #

A bridge receives a complete frame, checks enough link-layer validity to process it, and emits a new transmission on the selected egress. It does not decrement an Ethernet hop limit—there is none—and transparent endpoints need not know that bridging occurred. A router, by contrast, consumes the frame addressed to its local MAC entity and constructs a different link-layer frame for the next hop.

The learning rule is deliberately asymmetric #

For each accepted ingress frame, a learning bridge uses the source to update location state and the destination to make a forwarding decision. Conceptually, an FDB entry is:

$$(\text{forwarding context},\ \text{source MAC}) \rightarrow (\text{ingress port},\ \text{last seen},\ \text{state}).$$

The forwarding context is commonly a VLAN. The same MAC value learned in VLAN 10 and VLAN 20 denotes two independent entries.

Learning from sources is safe because the source identifies the station that demonstrably sent the frame through that ingress. Learning from destinations would be circular: a destination field expresses intent, not observed location.

Destination decisions #

After learning, the bridge looks up the destination in the same forwarding context:

“Flood” never means “send everywhere.” Port state, VLAN membership, filtering policy, group-registration state, and egress eligibility constrain the set. A VLAN-aware bridge must not leak a flooded frame into another VLAN merely because the physical trunk carries both.

Unknown unicast is normal during initial learning, after FDB aging, and after host movement. Persistent high unknown-unicast volume is evidence to investigate: asymmetric paths, one-way visibility, excessive aging, unstable endpoints, an exhausted table, or traffic whose return path never reaches the same learning domain.

Aging, movement, and MAC flapping #

Dynamic FDB entries expire after an aging interval so disconnected or moved stations do not remain pinned forever. Receiving the source again refreshes the entry. Seeing the same source on a new port moves its location.

This creates a useful diagnostic distinction:

• a single move near a host migration or link failover can be expected;
• repeated moves between ports are MAC flapping and often indicate a loop, duplicate address, unstable bond, or miswired topology;
• a stale entry causes temporary misforwarding until relearning, aging, or an explicit control-plane update corrects it;
• a static entry does not age, so incorrect static state persists until configuration changes.

FDB capacity is finite. If new sources cannot be learned, their return traffic is more likely to remain unknown and flood. Table exhaustion is therefore both a reliability and a security concern, but the evidence is table occupancy, learning failures, and flooding—not merely high broadcast traffic.

VLAN ingress classification #

Before forwarding, each accepted frame belongs to a VLAN context. Two common cases are:

• tagged ingress: an IEEE 802.1Q tag carries a VLAN identifier; the port must be allowed to receive that VLAN;
• untagged ingress: port configuration supplies a port VLAN identifier (PVID) or otherwise classifies the frame.

The 802.1Q tag contains:

• a three-bit priority code point (PCP) used by bridge traffic-class selection;
• a drop-eligible indicator (DEI);
• a twelve-bit VLAN identifier (VID).

VID 0 is priority-tagged traffic: it conveys priority while using the ingress classification for VLAN membership. VID 4095 is reserved. The existence of 12 bits does not mean every nominal value is a usable tenant or that VLANs form a globally unique namespace.

Ingress admission should fail closed for unexpected VLANs. A port that accepts every tag from an endpoint silently lets the endpoint choose forwarding context; a native/untagged mismatch between two devices can place the same bytes into different VLANs on each side.

Egress treatment is a separate decision #

After the FDB selects an egress, the bridge decides how that VLAN is represented on the outgoing link. A frame can leave tagged or untagged according to egress membership and port configuration. The VLAN remains part of the bridge's internal forwarding context even when no tag is emitted.

“Access port” and “trunk port” are useful operational terms, not two Ethernet frame species:

• an access-facing port usually maps untagged endpoint traffic into one VLAN and sends that VLAN untagged;
• a trunk carries several VLAN contexts, commonly with tags, and may also have one explicitly configured untagged/native context.

The most reliable trunk is symmetric and explicit: the same allowed VLANs, expected tag treatment, and native behavior at both ends. A trunk that is physically up but disagrees on those rules produces selective reachability that looks like an IP problem until the ingress context is inspected.

VLANs and broadcast domains #

Broadcast, unknown-unicast flooding, and ordinary MAC learning are scoped to a VLAN. Two hosts in different VLANs do not become adjacent merely because their switch ports share one chassis. Communication between those VLANs requires a network-layer forwarding function or another explicitly defined service.

This yields two complementary boundaries:

• a VLAN separates layer-2 forwarding contexts and broadcast replication;
• an IP subnet supplies network-layer addressing and next-hop semantics.

They are often designed one-to-one for clarity, but they are not mathematically identical. Multiple IP prefixes can exist in one VLAN, and misconfiguration can put one IP prefix across unintended VLANs. Diagnose the layer actually failing instead of assuming either mapping.

Worked forwarding example #

Suppose port 1 classifies untagged traffic into VLAN 10, port 3 is an untagged member of VLAN 10, and port 8 carries VLANs 10 and 20 tagged.

1. Host A sends from 02:00:00:00:00:0a to B on port 1.
2. The bridge assigns VLAN 10 and learns (10, A) → port 1.
3. If (10, B) → port 3 exists, only port 3 receives the frame, untagged.
4. If B is unknown, eligible VLAN-10 ports receive a copy: port 3 untagged and port 8 tagged. VLAN-20-only ports receive nothing.
5. B's reply lets the bridge learn (10, B) → port 3; subsequent unicast in both directions is selective.
6. If a MAC numerically equal to B appears in VLAN 20 on port 8, it updates (20, B) without changing (10, B).

This is the smallest useful model of a VLAN-aware switch: classify → learn source → look up destination → constrain egress → encode tag treatment.

Operational inspection #

On Linux, bridge state is exposed as separate objects rather than one opaque “switch table”:

bridge link show
bridge vlan show
bridge fdb show
bridge mdb show

Read them in that order. Port state decides whether forwarding is possible; VLAN membership decides the context; the FDB explains known unicast; the multicast database explains selective group replication. Hardware-offloaded bridges can maintain state in an ASIC, so also verify whether entries are marked or reported as offloaded and whether software and hardware views agree.

For a selective reachability fault, collect:

1. ingress port and observed tag state;
2. assigned VLAN/PVID and ingress admission result;
3. source FDB movement during the test;
4. destination lookup and selected egress set;
5. egress VLAN membership and tag treatment;
6. port spanning-tree state and drop counters;
7. captures on both sides of the bridge when state alone is insufficient.

The frame can be correct at ingress and absent at egress because of filtering, VLAN membership, spanning-tree state, table state, or queue loss. A capture from only the endpoint cannot distinguish those causes.

Common reasoning traps #

• “A switch learns where destinations are.” It learns source locations and uses that state for later destination lookups.
• “Unknown unicast is broadcast.” Both are flooded, but unknown unicast still names one individual destination and may become selective after learning.
• “The VLAN is the tag.” The VLAN is the forwarding context; untagged frames are classified into one too.
• “Trunk means every VLAN.” A trunk's eligible set is configured and should be intentionally constrained.
• “The FDB is ARP.” An FDB maps MAC plus forwarding context to a bridge port. ARP maps an IPv4 address to a link-layer address at an IP adjacency.
• “A VLAN is sufficient isolation.” VLAN membership constrains bridging; admission, routing, filtering, and management controls determine the actual security boundary.
• “A duplicate frame proves the sender retransmitted.” A layer-2 loop or parallel observation points can duplicate frames before the sender knows anything happened.