When you plug a laptop into a switch, or when a data center engineer designs a new server room, someone somewhere had to decide how all the cables and devices connect to each other. This “how” is called network topology, and it is one of the most foundational ideas in networking.
Long before we had smartphones and cloud computing, network engineers had to solve a very basic problem: how do you connect multiple computers so they can all talk to each other reliably, affordably, and in a way that’s easy to troubleshoot? Over decades of trial and error, three core categories of architecture emerged as the building blocks of almost every network you’ll encounter today: Bus, Ring, and Hierarchical Star.
This article explains each of these from first principles, in plain English, with practical examples from Linux, Cisco, and Python, so that both beginners and working professionals can understand not just what they are, but why they exist and when to use them.
What Is a Network Topology?
A network topology is the arrangement of nodes (computers, switches, routers, printers, servers) and the links (cables or wireless connections) that connect them. Topology can refer to:
- Physical topology: how cables and devices are physically arranged in a room or building.
- Logical topology: how data actually flows between devices, regardless of physical layout.
These two can differ. For example, a network might be physically wired as a star but logically behave like a bus (this was common in old Ethernet hubs).
Category 1: Bus Topology
What It Is
In a bus topology, every device connects to a single shared communication line, called the “bus” or “backbone.” Think of it like a single hallway with rooms (devices) opening directly onto it. When one device sends data, it travels down the whole bus, and every other device “hears” it, but only the intended recipient processes it.
How It Works
- A device wants to send data.
- It places the data onto the shared cable.
- The data travels in both directions along the bus.
- All devices receive the signal, but only the device whose address matches the destination address accepts and processes it.
- Terminators are placed at both ends of the bus to absorb the signal and prevent it from bouncing back (signal reflection), which would cause interference.
Historical Context
Bus topology was extremely common in early Ethernet networks using coaxial cable, specifically 10BASE5 (“Thicknet”) and 10BASE2 (“Thinnet”). A single length of coax cable ran through a building, and computers tapped into it using T-connectors or vampire taps.
Advantages
- Low cost: requires the least amount of cabling compared to other topologies.
- Simple to set up: for a small number of devices, it’s quick to install.
- Good for temporary networks: useful for small, short-term LANs.
Disadvantages
- Single point of failure: if the main cable breaks, the entire network goes down.
- Difficult to troubleshoot: finding the exact break point in the cable can be time-consuming.
- Performance degrades with more devices: since all devices share the same bandwidth, adding more nodes means more collisions and slower speeds.
- Limited cable length: signal degradation (attenuation) limits how long the bus can be without repeaters.
Real-World Example
Imagine an old computer lab in the 1990s with ten PCs connected using thin coaxial cable in a straight line, with a BNC T-connector at each PC and 50-ohm terminators at both ends. If a student unplugged the cable in the middle to move their desk, everyone on that segment lost connectivity — a classic illustration of the single point of failure problem.
Category 2: Ring Topology
What It Is
In a ring topology, each device connects to exactly two other devices, forming a continuous loop, or “ring.” Data travels around the ring in one direction (unidirectional) or sometimes both directions (bidirectional, for redundancy).
How It Works
- Data leaves the source device and travels to the next device in the ring.
- Each device examines the destination address. If it’s not the intended recipient, it simply forwards (repeats) the data to the next device.
- This continues until the data reaches its destination, which accepts it and typically also forwards an acknowledgment.
- In “Token Ring” networks (an early IBM standard), a special data packet called a token circulates around the ring. A device can only transmit when it holds the token, which prevents collisions entirely.
Historical Context
Token Ring (IEEE 802.5) was IBM’s answer to Ethernet in the 1980s and 1990s. Fiber Distributed Data Interface (FDDI) also used a dual-ring architecture for high-speed backbone networks, often in campus or metropolitan settings, using a second ring as a backup in case the primary ring failed.
Advantages
- Predictable performance: because access is controlled by a token, there are no collisions, and performance is more predictable under heavy load compared to bus topology.
- Equal access: every device gets a fair chance to transmit since the token passes around evenly.
- Dual-ring designs offer redundancy: if one ring breaks, traffic can be rerouted onto the second ring (as in FDDI).
Disadvantages
- Single ring failure can be catastrophic: in a simple single ring, one broken link or failed device can disrupt the entire network (unless a dual ring or ring-healing mechanism exists).
- More complex to install and maintain than a simple bus.
- Adding or removing devices is disruptive: because each device is both an endpoint and a repeater, temporarily breaking the ring is often necessary.
Real-World Example
A metropolitan area network (MAN) connecting several buildings on a university campus using FDDI dual-ring fiber is a classic real-world use of ring topology. If a backhoe accidentally cuts one of the two fiber rings, the network can “wrap” traffic onto the surviving ring and continue operating, which is a huge advantage over a single bus cable failure.
Category 3: Hierarchical Star Topology
What It Is
The hierarchical star (sometimes called “tree” or “extended star”) topology is the dominant architecture in almost all modern networks. In a basic star, every device connects to a single central device (a switch or hub). In a hierarchical star, multiple star networks are connected together in layers, forming a tree-like structure with a clear hierarchy: core, distribution, and access layers.
How It Works
- Access layer: end devices (PCs, IP phones, printers) connect to access switches.
- Distribution layer: access switches connect upward to distribution switches, which aggregate traffic from multiple access switches.
- Core layer: distribution switches connect to core switches/routers, which handle high-speed forwarding between different parts of the network and often connect to the internet or a WAN.
This is precisely the Cisco three-tier hierarchical network design model, one of the most widely taught and implemented designs in enterprise networking.
graph TD
Core[Core Layer<br/>High-speed backbone]
Dist1[Distribution Switch A]
Dist2[Distribution Switch B]
Acc1[Access Switch 1]
Acc2[Access Switch 2]
Acc3[Access Switch 3]
Acc4[Access Switch 4]
PC1[PC/Phone/Printer]
PC2[PC/Phone/Printer]
PC3[PC/Phone/Printer]
PC4[PC/Phone/Printer]
Core --> Dist1
Core --> Dist2
Dist1 --> Acc1
Dist1 --> Acc2
Dist2 --> Acc3
Dist2 --> Acc4
Acc1 --> PC1
Acc2 --> PC2
Acc3 --> PC3
Acc4 --> PC4Advantages
- Fault isolation: if one access switch fails, only the devices connected to it are affected — the rest of the network keeps working.
- Scalability: new branches (access switches) can be added without redesigning the whole network.
- Easy troubleshooting: because of the clear hierarchy, engineers can isolate problems layer by layer.
- Centralized management: policies, VLANs, and security can be applied at logical points (distribution or core) rather than everywhere.
- Redundancy is easy to add: dual uplinks, spanning tree protocol (STP), and routing protocols allow for backup paths.
Disadvantages
- More cabling required: every device needs its own cable back to a switch, so a hierarchical star uses much more cable than a bus.
- Dependency on central devices: if a distribution or core switch fails without redundancy, many devices lose connectivity.
- Higher initial cost: more switches and structured cabling infrastructure are required upfront.
Real-World Example
A modern corporate office is the textbook example. Each floor has an access switch (say, a Cisco Catalyst 9200) in a wiring closet, connecting all the PCs and IP phones on that floor. Each floor’s access switch connects via fiber uplinks to a distribution switch (a Cisco Catalyst 9500) in the main equipment room, and multiple distribution switches connect to a core switch/router that handles routing between floors and out to the internet.
Comparison Table: Bus vs. Ring vs. Hierarchical Star
| Feature | Bus | Ring | Hierarchical Star |
|---|---|---|---|
| Cabling required | Low | Moderate | High |
| Fault tolerance | Very poor (single point of failure) | Poor (single ring) / Good (dual ring) | Excellent, with redundancy design |
| Scalability | Poor | Moderate | Excellent |
| Troubleshooting ease | Difficult | Moderate | Easy (isolated per layer) |
| Performance under load | Degrades quickly | Predictable (token-based) | Excellent, high-bandwidth uplinks |
| Common use today | Legacy/rare | Legacy/rare (still used in some industrial & SONET/SDH rings) | Standard in modern LANs/enterprise networks |
| Example technology | 10BASE2, 10BASE5 coax Ethernet | Token Ring, FDDI | Ethernet switches, Cisco 3-tier design |
Linux Example: Visualizing Network Topology
On a Linux machine, you can inspect your own network topology information using standard tools. For example, to see your local network interfaces and their connections:
# Show all network interfaces and their status
ip link show
# Show routing table (useful for understanding hierarchy: which gateway/core you route through)
ip route show
# Trace the path packets take toward a destination — reveals hierarchical hops
traceroute 8.8.8.8
# Use bridge utilities to inspect a Linux bridge acting as a simple "star" hub for VMs
bridge link show
traceroute is especially useful for understanding hierarchical star topology in the real world: each hop typically represents a jump from access to distribution to core to ISP, in a layered fashion, mirroring the hierarchical star design used in enterprise and ISP networks.
Cisco Example: Configuring a Simple Hierarchical Star
Here is a simplified Cisco IOS configuration snippet showing an access switch uplinked to a distribution switch — a basic building block of hierarchical star design.
! On the Access Switch
enable
configure terminal
hostname ACCESS-SW1
interface GigabitEthernet0/1
switchport mode access
switchport access vlan 10
description Connected-to-PC
!
interface GigabitEthernet0/24
switchport mode trunk
description Uplink-to-Distribution
switchport trunk allowed vlan 10,20,30
end
! On the Distribution Switch
enable
configure terminal
hostname DIST-SW1
interface GigabitEthernet0/1
switchport mode trunk
description Downlink-from-Access-SW1
switchport trunk allowed vlan 10,20,30
!
interface GigabitEthernet0/2
no switchport
ip address 10.0.0.1 255.255.255.252
description Uplink-to-Core
end
This clearly demonstrates the layered nature of hierarchical star: access switches trunk up to distribution switches, and distribution routes up to the core.
Python Example: Simulating Topology Behavior
Here’s a simple Python simulation to conceptually compare how a message travels in bus vs. ring vs. star topologies. This is educational, not a production networking tool.
class Network:
def __init__(self, devices):
self.devices = devices
def bus_transmit(self, sender, message):
print(f"{sender} broadcasts on shared bus: '{message}'")
for device in self.devices:
if device != sender:
print(f" {device} hears the message on the bus")
def ring_transmit(self, sender, receiver, message):
idx = self.devices.index(sender)
hops = 0
current = sender
while current != receiver:
next_idx = (idx + 1) % len(self.devices)
current = self.devices[next_idx]
idx = next_idx
hops += 1
print(f" Passing token/message to {current}")
print(f"{sender} -> {receiver}: delivered in {hops} hops around the ring")
def star_transmit(self, sender, receiver, message):
print(f"{sender} sends '{message}' to central switch")
print(f" Switch forwards directly to {receiver}")
devices = ["PC-A", "PC-B", "PC-C", "PC-D"]
net = Network(devices)
print("--- Bus Topology ---")
net.bus_transmit("PC-A", "Hello Network")
print("\n--- Ring Topology ---")
net.ring_transmit("PC-A", "PC-D", "Hello Network")
print("\n--- Star Topology ---")
net.star_transmit("PC-A", "PC-D", "Hello Network")Running this script prints out how each topology handles the same message differently — bus broadcasts to everyone, ring passes hop by hop, and star goes directly through a central point.
Best Practices
- Always plan for redundancy in hierarchical star designs — use dual uplinks and protocols like Spanning Tree Protocol (STP) or its faster successor Rapid PVST+ to prevent loops while maintaining backup paths.
- Avoid legacy bus topology for anything beyond small, non-critical, temporary setups — it does not scale and has no fault tolerance.
- Use dual-ring designs (not single ring) if ring topology must be used, especially for critical infrastructure like SONET/SDH telecom backbones.
- Document your physical and logical topology separately — many outages happen because engineers only understood one layer and not the other.
- Design hierarchical networks in three clear layers (access, distribution, core) even in smaller networks, because it makes future scaling much easier.
- Label and color-code cabling according to the layer/hierarchy it belongs to, to speed up troubleshooting.
Troubleshooting Guide
| Symptom | Likely Topology-Related Cause | Suggested Fix |
|---|---|---|
| Entire network down at once | Bus topology, cable break, or missing terminator | Inspect the full length of the bus cable; check terminators |
| Network slows drastically as more devices are added | Bus topology, too much shared bandwidth contention | Migrate to switched hierarchical star |
| One device failure takes down the whole ring | Single ring topology without redundancy | Implement dual-ring or migrate to star |
| One floor/department loses connectivity, rest of building fine | Hierarchical star, access switch or its uplink failed | Check access switch, verify uplink port and cable to distribution layer |
| Intermittent slow performance across the whole building | Distribution or core layer congestion or failure | Check distribution/core switch CPU, interface errors, and uplink utilization |
| Loops causing broadcast storms | Redundant links without STP enabled | Enable and verify Spanning Tree Protocol configuration |
Case Study: Migrating a Growing Startup Off a Flat Network
A fast-growing startup began its life with a simple flat network: a single switch in a closet with every device — servers, employee laptops, and a handful of IoT sensors on the office floor — plugged into it directly, functioning essentially as one large star with no distribution or core layering. This worked fine with fifteen employees. By the time the company reached eighty employees across two floors, the single switch had become severely oversubscribed, a single failed port could take down a disproportionate number of devices at once because patch cables had been haphazardly extended and re-patched over time without documentation, and any troubleshooting required physically tracing cables since there was no logical structure to reason about.
The company’s newly hired network engineer redesigned the infrastructure explicitly around the hierarchical star model described in this article: an access switch per floor, a small distribution switch aggregating both floors, and a core router/firewall handling internet egress and inter-VLAN routing. Critically, the redesign also introduced redundant uplinks between access and distribution layers with Rapid PVST+ enabled to prevent loops while allowing automatic failover. Within the first month after the migration, a failed uplink cable on one floor caused zero visible disruption to end users, since traffic automatically failed over to the redundant link — a scenario that, under the old flat network, would have caused a significant outage. This case captures the central lesson of hierarchical design in practice: it’s not simply about looking organized on a diagram, it’s about converting single points of failure into isolated, recoverable events.
Frequently Asked Questions
Is ring topology completely obsolete today, or does it still have real-world uses? While rare in typical LAN environments, ring-based architectures persist in certain telecom and industrial contexts — SONET/SDH backbone rings and some industrial Ethernet ring protocols (like Media Redundancy Protocol in industrial automation) still leverage ring-style redundancy concepts, just implemented over modern switched infrastructure rather than classic Token Ring hardware.
Can a network combine more than one topology type at once? Yes, and in practice most real-world networks do — a data center might use a hierarchical star (or a more specialized leaf-spine variant) for its switching fabric while a WAN connecting multiple sites might use a partial-mesh or ring-like redundant path design between locations.
Why did bus topology fail to scale, exactly? Because every device shares the same physical medium and thus the same total bandwidth, and because collisions increase disproportionately as more devices contend for that shared medium, both factors compound as device count grows, quickly making a bus topology impractical beyond a small number of nodes.
What’s the practical difference between a “star” and a “hierarchical star”? A basic star has one central device connecting all endpoints directly; a hierarchical star adds multiple layers (access, distribution, core) so that no single device needs to directly handle every endpoint’s traffic, which is what actually enables scaling to large numbers of devices.
Does Spanning Tree Protocol relate to these topology categories? Yes directly — STP exists specifically to safely enable the redundant links that make hierarchical star networks fault-tolerant, by preventing the loops that redundant paths would otherwise create while still allowing automatic failover if a primary path fails.
Conclusion
Understanding bus, ring, and hierarchical star topologies is not just a history lesson — it’s the foundation for understanding why modern networks are built the way they are. Bus topology taught the industry the danger of single points of failure. Ring topology introduced the idea of orderly, collision-free access and built-in redundancy through dual rings. And hierarchical star topology combined the best lessons from both to become the gold standard for scalable, fault-tolerant, and manageable networks used in virtually every modern enterprise, campus, and data center today.
Whether you’re a beginner setting up a home lab or a professional architecting a multi-site enterprise network, recognizing these three core categories — and knowing their strengths and weaknesses — will help you make better design decisions and troubleshoot faster when something goes wrong.