Network topologies (Bus, Star, Ring, Mesh)

Once you have more than two hosts on a LAN, a new question shows up: how are they physically and logically wired to each other? Run one cable through every desk in a row? Run a cable from every desk back to a central box? The answer is a network's topology — the shape formed by its links — and that shape has real consequences for cost, reliability, and how badly one failure can hurt.

Physical vs. logical topology

Before going through the shapes, it's worth separating two things that get conflated: the physical topology is how the cables are actually run — which device is plugged into which. The logical topology is how data actually flows once it's on the wire, which doesn't always match the physical layout.

A modern Ethernet network makes the gap obvious. It is physically wired as a star — every device runs its own cable to a central box — but the earliest generations of that wiring behaved, logically, like one shared cable: every device on the segment could see every frame. So a physically star-shaped network absolutely can behave like a bus. Which one it behaves like depends entirely on what sits in the middle, and that's the next thing to pin down.

Bus topology

In a bus topology, every host connects to one shared cable, called the backbone. A signal sent by any host travels down the whole cable, and every other host on it can see the signal, picking out only the frames addressed to it.

Host A --- Host B --- Host C --- Host D
            (single shared backbone cable)

This was cheap — one cable, minimal hardware — which is why early Ethernet (10BASE5 and 10BASE2, using coaxial cable) used it. But it has a brutal weakness: the whole network depends on a single, unbroken cable. A break anywhere splits the network in two, or takes it all down, and only one host can transmit at a time without signals colliding — a real, physical event on shared coax where two overlapping electrical signals corrupt each other, requiring hosts to detect it and retransmit.

Bus topology as an actual physical wiring scheme is effectively extinct in production networks today. It's covered here because the logical idea — one shared medium, contention over who gets to talk — is still exactly how a Wi-Fi channel behaves. Every device on the same channel takes turns on shared airtime, which is why a crowded apartment building feels slow even when every individual link looks strong.

Star topology

In a star topology, every host runs its own cable back to one central device — a switch, historically a hub.

        Host A
          |
Host D -- Switch -- Host B
          |
        Host C

This is what essentially every modern wired LAN looks like. Losing one cable only knocks out the one host attached to it — the rest of the network keeps working, which is a massive reliability improvement over bus topology. The cost is that the central device is now a single point of failure for the whole segment; if it dies, every host connected to it loses connectivity at once. It also means more cable overall (one run per host, instead of one shared backbone) and depends on a piece of active equipment existing in the middle at all, which the earlier bus design didn't require.

The device in the middle is what decides whether the star is logically a star or logically a bus:

• A hub repeats every incoming signal out of every other port. Physically a star, logically still a bus — every frame reaches every device, and the collisions come right back with it.
• A switch learns which host sits on which port and forwards a frame only to the port that needs it. Same cabling, completely different behaviour.

Switches replaced hubs almost entirely once they became affordable, which is why "physically a star, logically a bus" is now a historical curiosity rather than something you'll wire up. It's still worth knowing, because it explains why some old documentation treats a star-wired network as a shared medium.

Ring topology

In a ring topology, each host connects to exactly two neighbors, forming a closed loop. Data travels around the ring, hop by hop, until it reaches its destination.

Host A --- Host B
   |          |
Host D --- Host C

Token Ring and FDDI (Fiber Distributed Data Interface) were the notable production uses of this shape. A ring can guarantee fair, collision-free access: a special frame called a "token" circulates the ring, and only whoever holds it may transmit, so there's never a fight over who gets to talk next.

The weakness is just as direct — a ring is a loop, and a single broken link turns a loop into a dead-end line. FDDI's answer was a second, redundant ring running in the opposite direction, so traffic could still get around a single break.

Ring topologies have mostly disappeared from general-purpose LANs, replaced by switched Ethernet's lower cost and simpler cabling. The underlying idea didn't disappear with them, though — some metro and carrier-grade fiber networks still move traffic hop by hop around a loop for exactly the same reason FDDI did: one break shouldn't take the whole thing down.

Mesh topology

In a mesh topology, hosts connect directly to multiple other hosts rather than through one central point. A full mesh connects every host to every other host; a partial mesh connects each host to several, but not all, others.

Host A ------- Host B
  |   \       /   |
  |    \     /    |
  |     \   /     |
Host D ------- Host C

Mesh is the most fault-tolerant shape — losing one link, or even one host, still leaves multiple paths between the remaining hosts. That resilience comes at a steep cost in cabling and configuration: a full mesh of n hosts needs n(n−1)/2 links, which grows fast enough that it's impractical much past a handful of nodes.

In practice, full mesh shows up in small, high-reliability contexts — a handful of core routers in a data center, for instance. Consumer "mesh Wi-Fi" products borrow the name but are almost always a partial mesh: three or four nodes cooperating and relaying for each other, not every node linked to every other one. The internet's backbone, at the level of how ISPs interconnect, is a large partial mesh too — heavily redundant in most places, but nowhere near every network wired directly to every other one.

Comparing the four

Reading a topology as a failure map

A small office has five developer machines connected through an old unmanaged switch. One morning all five machines lose access to the internal Git server, but the Wi-Fi still works. That failure pattern already tells you something useful.

If the office used a bus topology, a single break in the shared cable could disrupt every host past the break. In a modern star topology, the likely suspects are different: the switch lost power, the uplink from the switch to the router failed, or the Git server sits behind the same failed switch. The topology turns a vague outage into a smaller search space.

Only one desk is down       -> check that host, its cable, and its switch port
One switch group is down    -> check the switch and its uplink
The whole office is down    -> check the router, ISP link, or upstream service

Topology is not just a diagram for documentation. It is a failure map, and the practical reason to understand it is blast radius: the shape of the network tells you, before you touch anything, which failures can only be local and which failures must be shared.

Interview trap

A star topology's "single point of failure" is the central switch, not the cabling — but a topology diagram alone can't tell you whether two hosts on that same star can actually reach each other. It's tempting to answer "why can't these two hosts talk" with a topology fact ("they're both on the star, so they should connect fine"), when the real answer often lives one layer up, in VLAN assignment or ARP state, that a topology diagram never shows. An interviewer asking about topology resilience is often listening for whether you distinguish physical connectivity (the shape of the cabling) from logical reachability (whether two ports are actually placed on the same broadcast domain).

Practical scenario: one host on the star, unreachable by name and by address

A star-wired office LAN has five hosts hanging off one switch. One of them, 10.0.5.55, was reachable yesterday. Today, ping 10.0.5.55 from another host on the same switch just hangs and then reports failure — not a slow reply, no reply at all.

The switch itself isn't the suspect yet: everything else on the star still reaches everything else. That already narrows the search space the way the earlier five-desk scenario did — this isn't the "whole segment down" pattern, it's a single-host pattern. On a star topology, a single dead host usually means one of: the host is powered off, its cable/port died, or the local network can't currently translate its IP address into a MAC address to put a frame on the wire at all. Check the last one first, since it's one command:

ip neigh show 10.0.5.55

10.0.5.55 dev eth0  FAILED

FAILED means this host tried to resolve 10.0.5.55 to a MAC address via ARP and got no answer — the ARP request went out as a broadcast to every device on the segment, and nothing claimed that address. Compare that with a healthy entry elsewhere on the same table:

ip neigh show

10.0.5.1 dev eth0 lladdr 5c:1a:6f:22:4b:e0 REACHABLE
10.0.5.55 dev eth0  FAILED
10.0.5.60 dev eth0 lladdr 08:00:27:9c:11:07 STALE

Three different states, three different meanings: REACHABLE was confirmed recently and is trustworthy right now; STALE is cached and will be quietly re-verified before its next use, which is normal and not a problem; FAILED means resolution was actively attempted and came back empty. Only the last one points at an actual fault.

An ARP failure at this layer has a short list of real causes: the host is genuinely off or unplugged (nothing answers a broadcast if nothing is listening), its IP address was reassigned to a different device or changed without updating your records, or — on a segment split into VLANs — the querying host and 10.0.5.55 are wired to the same physical switch but placed in different VLANs, which makes them behave as if they were on entirely separate segments despite the shared cabling. Physical topology (the star) says they're one hop apart; logical topology (the VLAN) can still say otherwise, which is exactly the physical-vs-logical distinction from the top of this article showing up as a real incident instead of a definition.

Confirm which of those it is by checking the switch's own port status and VLAN assignment (vendor-specific, e.g. show interfaces status on a Cisco switch) rather than continuing to guess from the host side alone — ip neigh tells you resolution failed, not why.

Practice exercises

1. Sketch, on paper or in a text file, the topology of your own home or office network — which device connects to which. Identify the single point of failure in your sketch.
2. Explain why a switch failing in a star topology is worse, in terms of number of affected hosts, than any single cable failing in the same topology.
3. A company wants zero downtime even if any one link fails between four core routers. Which topology from this article satisfies that, and how many links does it require?
4. For each topology in the comparison table, name the one failure that takes the whole segment down and the one failure that only affects a single host. Two of the four have the same answer for both questions — find them and explain why.

Notice what every one of those exercises has in common: the answer depends on knowing which device reads which part of a frame, and where in the delivery process it does so. A switch makes forwarding decisions on hardware addresses; a router makes them on logical addresses; a firewall makes them on port numbers. Those are three different jobs at three different levels of the same stack, and networking has a standard vocabulary for naming those levels precisely. That vocabulary is next: OSI model (7 layers).

Sources

• IEEE, IEEE 802.3 Ethernet Working Group — the standard underlying modern star-wired switched Ethernet.
• Cloudflare Learning Center, What is network topology?
• IETF, RFC 826 – An Ethernet Address Resolution Protocol — describes the shared-segment assumptions early Ethernet topologies were built on.