Switch
Plug ten computers into a single hub and every one of them hears every bit any other one sends — a topic the next article covers in detail. A switch was built to fix exactly that waste: deliver each frame only to the one device that actually needs it, while still letting every port talk to every other port whenever it wants to. It does this by learning, not by being told.
Building the forwarding table by watching, not asking
A switch keeps a MAC address table — sometimes called a CAM table, for the content-addressable memory it's typically implemented in — mapping MAC addresses to the physical port they were last seen on. Nobody configures this table by hand. The switch builds it by watching traffic go by.
When a frame arrives on a port, the switch reads its source MAC address and records "this address lives behind this port" in its table, refreshing the entry's age if it's already there. Only then does it look at the frame's destination MAC address:
- If the destination is already in the table, the switch forwards the frame out that one specific port. Every other port never sees it.
- If the destination isn't in the table yet, the switch floods the frame out every port except the one it arrived on — an educated guess, since one of those devices should be the actual recipient, and whichever one replies will teach the switch where that address lives for next time.
Table entries don't last forever; most switches age out an entry after five minutes of inactivity by default, so a device that's been silent for a while forces one more flood the next time something needs to reach it.
Switch MAC address table
Port MAC address Age (s)
1 08:00:27:4e:66:a1 12
3 5c:1a:6f:22:4b:e0 3
7 08:00:27:9c:11:07 45
This is the same kind of table, learned the same way, as the "two machines appear as one" scenario in the MAC address article: a switch simply updates whichever port it most recently saw a given address on, with no concept of "this address should only ever appear on port 3."
Collision domains, broadcast domains, and why switches changed both
Every port on a switch is its own collision domain — the set of devices that could try to transmit at the same time and interfere with each other on a shared medium. On a hub, every device shares one collision domain, so only one device can transmit at a time without a collision. A switch gives every port its own dedicated collision domain, which is what makes full-duplex operation possible: a device can send and receive simultaneously on its own point-to-point link to the switch, with nothing else competing for that same wire.
What a switch does not do, by default, is split up the broadcast domain — the set of devices that receive a frame sent to the broadcast address ff:ff:ff:ff:ff:ff. A broadcast still reaches every port on the switch, the same way it would on a hub, because a switch has no address to look up for a broadcast frame; it floods it deliberately, every time, by definition. ARP requests rely on exactly this behavior. Splitting a broadcast domain into smaller pieces on a switch is possible, but it requires configuring VLANs (Virtual LANs) — logically separate broadcast domains carved out of the same physical switch hardware — a configuration topic beyond what this article covers.
Reading a switch's own table
On a managed switch, an administrator can query this table directly. The exact command varies by vendor, but the shape of the output is the same everywhere — a list of MAC addresses, the VLAN each belongs to, and the port it was learned on:
Switch# show mac address-table
Vlan Mac Address Type Ports
---- ----------- ---- -----
1 08:00:27:4e:66:a1 DYNAMIC Gi0/1
1 5c:1a:6f:22:4b:e0 DYNAMIC Gi0/3
1 08:00:27:9c:11:07 DYNAMIC Gi0/7
On an unmanaged home or small-office switch — the kind with no configuration interface at all — this same learning process still happens internally; you simply can't inspect the table, because the device offers no way to ask it.
Where beginners get confused
A switch operates almost entirely at Layer 2 and has no concept of IP addresses in its basic forwarding logic — it doesn't need one, because MAC addresses are all it uses to decide where a frame goes. This is easy to state and easy to forget in practice: people sometimes expect a switch to be able to block traffic by IP address or subnet the way a firewall does, and a purely Layer 2 switch simply has no mechanism to do that. (Some higher-end "Layer 3 switches" blur this line by adding routing capability, but that's an added feature layered on top of Layer 2 switching, not something ordinary switching does inherently.)
A second common confusion: assuming a switch guarantees delivery. It doesn't, in the sense that matters for reliability — a switch will happily forward a frame into a full output queue and drop it if the port is oversubscribed, exactly the kind of loss TCP exists to detect and recover from. A switch moves frames efficiently; it makes no promise that every frame arrives.
Practical scenario: a broadcast storm from an accidental loop
A junior engineer, trying to extend a switch's port count, plugs a spare unmanaged switch into the main office switch — using two cables between them instead of one, by mistake, to "add more bandwidth." Within seconds, the entire office loses network connectivity. Every port on the main switch shows heavy traffic, but nothing useful is getting through, and the switch's CPU utilization spikes.
The two cables created a physical loop. A broadcast frame — an ARP request, for instance — enters the loop and gets flooded back onto the same segment it came from, over and over, multiplying with every pass since each switch dutifully floods anything it doesn't have a table entry for. This is a broadcast storm, and unlike a routed IP packet, an Ethernet frame has no TTL field to expire it — nothing at Layer 2 stops the same frame from circulating forever, so the loop saturates every link in it almost instantly.
Production switches defend against exactly this failure mode with the Spanning Tree Protocol (STP), standardized in IEEE 802.1D, which detects redundant paths between switches and automatically blocks one of the duplicate links to keep the topology loop-free — while still keeping the blocked link ready as a backup if the primary path fails. An unmanaged switch typically has no STP at all, which is exactly why the accidental second cable in this scenario caused a total outage instead of a self-healing failover.
Warning
Never connect two switches with more than one cable unless every switch involved is confirmed to be running STP (or you're deliberately configuring a supported link-aggregation bundle, which is a different, intentional mechanism). On unmanaged hardware, a second cable between two switches is not redundancy — it's a loop.
Practice exercises
- A switch receives a frame destined for a MAC address it has never seen before. Walk through, step by step, what the switch does with that frame and how its table changes as a result.
- Explain why giving every port on a switch its own collision domain is what makes full-duplex Ethernet possible, and why that same change does nothing to shrink the broadcast domain.
- A colleague says "our switch guarantees every frame gets delivered." Using what you know about output queues and drops, explain what's wrong with that claim and which protocol actually provides delivery guarantees on top of it.
- Sketch (on paper or in a text diagram) two switches connected by two separate cables, and trace what happens to a single broadcast frame injected at one port, assuming neither switch runs STP.
A switch decides where a frame goes within one local network. The moment traffic needs to leave that network entirely — reach a different subnet, a different building, or the internet — a switch has nothing left to offer, and the job passes to the device this module already introduced: the router.