Skip to content

Hub

The switch article described how a device learns which MAC address lives behind which port, so it can forward a frame to exactly one destination. A hub does none of that. It's worth understanding one anyway, not because you're likely to deploy one today, but because a hub is the plainest possible illustration of the problem switching was invented to solve — and because hubs haven't entirely disappeared from a network engineer's toolkit, for reasons that turn out to be genuinely useful.

A repeater with more than two ports

A hub is a Layer 1 device — it operates purely on electrical signals, with no awareness of MAC addresses, IP addresses, or frames as structured data at all. When an electrical signal arrives on one port, the hub simply regenerates and repeats it out every other port, unconditionally. It doesn't read a destination address because, at Layer 1, there's no concept of an address to read — a hub sees voltage transitions, not Ethernet frames.

The practical consequence: every device connected to a hub is on the same collision domain, and every device receives every bit any other device transmits, whether it's the intended recipient or not. A network interface card has to actively filter out traffic addressed to other MAC addresses in software or firmware — the hub itself makes no attempt to spare it the trouble.

Why sharing one collision domain is expensive

Ethernet's original access method, CSMA/CD (Carrier Sense Multiple Access with Collision Detection), was designed for exactly this shared-medium situation. Before transmitting, a device listens to confirm the wire is idle; if two devices happen to transmit at nearly the same moment anyway, the signals collide, both devices detect the corruption, and both back off for a random interval before retrying. This works, but it means only one device on the whole hub can transmit successfully at any given instant — the "multiple access" part of the name is quite literal, and so is the cost: add more devices to a hub and the odds of a collision on any given transmission attempt go up, not down. A hub can also only run half-duplex: a device can send or receive, never both at once, because the shared medium has no way to guarantee the wire is clear for two directions simultaneously.

A switch, by contrast, gives every port its own dedicated collision domain and its own full-duplex link, which is the specific improvement that made hubs commercially obsolete once switch prices fell far enough in the late 1990s and early 2000s. IEEE 802.3, the standard that defines Ethernet at every speed from the original 10 Mbps up through modern multi-gigabit links, still documents repeater-based operation as part of its historical scope — but no current Ethernet equipment shipped today is built around it.

Where a hub still earns its place

There's one legitimate, still-current use for exactly the property that made hubs obsolete everywhere else: passive packet capture. If you want to observe every frame crossing a link — for troubleshooting, for security monitoring, or simply to learn what's actually on the wire — a switch actively works against you, because it forwards each frame only to its intended destination and nowhere else. Plugging a laptop into a spare switch port shows that laptop only its own traffic, never anyone else's.

An old-fashioned hub inserted inline on a link doesn't have this problem, because it was never capable of selective forwarding in the first place: every port sees everything, including a monitoring device plugged into a spare port. Purpose-built network taps are the modern, more reliable version of the same idea, and many managed switches offer a SPAN or mirror port feature that copies traffic to a monitoring port in software instead. All three approaches solve the same problem a hub solves by accident: getting a full, unfiltered copy of the traffic on a link to a packet-capture tool without disturbing the traffic itself — the subject of a later part of this module.

Practice exercises

  1. Four devices share a hub. Device A starts transmitting a frame to Device B. Explain what Devices C and D receive on their own ports during that transmission, and why — even though neither is the intended recipient.
  2. A network engineer wants to capture every packet flowing between a server and a switch for troubleshooting, but the switch has no SPAN/mirror port feature. Explain why temporarily inserting an old hub inline would let a laptop plugged into a spare port see that traffic, when plugging the same laptop into a spare switch port would not.

A hub floods every bit to every port because it has no concept of an address to make a decision with. Give a device that same physical position on the network but the ability to actually inspect what's passing through and decide whether it should be allowed at all, and you have a fundamentally different device: a firewall.

Sources