Switches and the Forwarding Table

A switch forwards frames between ports based on a learned MAC address table — sometimes called the CAM table or, on Linux bridges, the forwarding database. It watches the source MAC of every frame to learn which host sits behind which port, then sends each unicast frame out only the one port where its destination lives. That selectivity is the entire difference between a switch and the dumb hub it replaced, which repeated every frame out every port and let the hosts sort it out.

The table is built passively and ages out. Nobody configures it; the switch fills it from observed traffic and expires entries that go quiet, typically after 300 seconds. When a destination is not in the table, the switch has no choice but to flood the frame everywhere except the port it arrived on — the same fallback a hub does always, but for a switch it is the exception, not the rule.

MAC Learning

Learning is the source half of every forwarding decision. When a frame arrives on port 3 with source MAC aa:bb:cc:11:22:33, the switch records "that MAC is reachable via port 3" and resets the entry's age timer. The next frame destined to that MAC then goes out port 3 alone. A host that stays silent for longer than the aging time disappears from the table and its next inbound frame gets flooded until it speaks again.

A single port can map to many MACs — that is normal when a downstream switch, a hypervisor, or a VM host sits behind it. The table caps at a fixed size, tens of thousands of entries on a typical access switch, and what happens when it fills is the basis of a classic attack covered below. You can read and seed the table directly on a Linux bridge.

# the learned forwarding database on a Linux bridge
bridge fdb show br0
# aa:bb:cc:11:22:33 dev eth1 master br0          <- learned, dynamic
# dd:ee:ff:44:55:66 dev eth2 master br0 permanent <- static entry
bridge fdb add 02:00:00:00:00:01 dev eth2 master  # pin a MAC to a port

Unknown dst

→

Flood all ports

→

Learn source → port 3

→

Forward unicast

Forwarding, Flooding, and Filtering

Every frame triggers one of three decisions. Forward: the destination MAC is in the table on a different port, so send it out that port only. Flood: the destination is unknown, broadcast, or unknown-multicast, so send it out every port except the ingress port. Filter: the destination is in the table on the same port the frame arrived on, so the two hosts are on the same segment and the switch drops it — they already heard each other.

Unknown-unicast flooding is the one people forget. When a destination has aged out or never been seen, its unicast frames are flooded like a broadcast until the destination replies and the switch relearns it. On a stable network this is rare; on a network with asymmetric routing or very short aging timers it can become a constant background of flooded traffic hitting ports that should never see it.

Collision Domains versus Broadcast Domains

A switch puts every port in its own collision domain. On a full-duplex switched link there are effectively no collisions at all — each port is a private conversation between the switch and one host, which is why switched Ethernet retired the shared-medium collision logic that hubs needed. Each port is its own dedicated bandwidth, not a slice of a shared pipe.

What a plain switch does not break up is the broadcast domain. A broadcast frame floods out every port, so by default every host on a switch — and on every switch chained to it — is in one broadcast domain. Only a VLAN (Topic 09) or a router boundary splits that. This is the single most important limit of layer-2 switching: it scales bandwidth beautifully and contains broadcast not at all.

Cut-Through versus Store-and-Forward

A store-and-forward switch reads the entire frame, validates the FCS, and only then forwards it — so it never propagates a corrupt frame, at the cost of buffering the whole thing first. A cut-through switch starts forwarding as soon as it has read the 6-byte destination MAC, cutting latency to a fraction of a microsecond but passing along runts and corrupt frames it has not yet finished checking.

For most networks store-and-forward is the right default; the latency difference is sub-microsecond and not worth forwarding garbage. Cut-through earns its place in latency-sensitive fabrics — high-frequency trading, some HPC and storage networks — where shaving a few hundred nanoseconds per hop matters more than dropping the occasional bad frame at the edge instead of the core.