You’ve seen the diagrams. Bus networks. Ring topologies. They all have one fatal flaw. A single break in the chain and everything stops.
Star networks look safer. You’ve got a central switch. Every node plugs into it. If one computer dies, the rest stay online. But there’s a trap. That central switch? It’s a single point of failure.
Look at the setup below.
![Diagram description: A network with Switch A, Switch B, and Switch C. Nodes are connected to each switch. Switch A and C are connected to Switch B.]
In this scenario, Switch B is the backbone. It connects Switch A and Switch C.
If Switch A fails, the nodes on A go dark. But the nodes on B and C still talk to each other. Same if Switch C fails. Partial outage. Manageable.
But if Switch B dies?
Everything goes to zero. The entire network collapses. Why? Because B is the bridge. No bridge, no traffic.
This is where redundancy comes in. It’s not just about having backup power or extra hard drives. It’s about architectural resilience.
What if we change the physical layout?
Imagine adding a direct link between Switch A and Switch C. A redundant segment.
Now, if Switch B fails, A can still talk to C. The path changes. The traffic reroutes. The network stays up.
That’s the core of network redundancy. It’s not magic. It’s just a second way to get from point X to point Y.
But adding cable isn’t enough. You need protocols that understand this redundancy. Otherwise, you create loops. And loops crash networks faster than a dead switch.
We’re just scratching the surface here. The real work happens when you start talking about spanning tree protocols and failover times.
But first, you have to see the problem. And the problem is simple.
Dependence on a single point of failure.
Eliminate that, and you survive the next hardware glitch.
The first switch dies. The second takes over. Traffic keeps moving.
This is the beauty of network redundancy. You’ve killed the single point of failure. If one piece of hardware bricks itself, the loop stays closed. The network breathes.
But now we have a new problem.
The Loop of Death
Imagine two switches connected by two different cables. Or maybe a third switch joins the party. Now you have paths everywhere.
It works great for redundancy. Until it doesn’t.
When a switch sends out a frame and doesn’t know where it goes, it floods it to every port. In a simple line topology, that frame hits the end and stops. In a loop? It bounces forever.
Broadcasts multiply. Unicast frames bounce back and forth. Suddenly, your network isn’t just slow. It’s dead. The CPU on every switch spikes to 100%. Packets drop. The whole infrastructure grinds to a halt.
This is the broadcast storm. It’s not a feature. It’s a fire drill.
Stopping the Loop
So how do you keep the physical redundancy without the logical chaos?
You need a protocol. Something that says, “Hey, I see two paths. I’ll block one. If this one breaks, I’ll unblock the other.”
Enter Spanning Tree Protocol (STP).
It’s been around since the 80s. It’s old. It’s clunky. But it works. STP looks at all the links between switches. It calculates the best path to the root bridge (the main switch). Then it puts every other redundant link into a blocking state.
Traffic flows. The backup line sits there, idle. Ready.
If the primary cable gets cut? The blocking port wakes up. It becomes active. The network heals.
It takes a few seconds though. Maybe thirty. In that time, users stare at loading bars.
The Faster Fix: Rapid Spanning Tree
Thirty seconds is an eternity in server time. If you’re running a data center, or even just a busy office, thirty seconds of downtime is unacceptable.
Enter Rapid Spanning Tree Protocol (RSTP), or 802.1w.
It’s the same basic idea. Block redundant links. Unblock them when needed. But RSTP cuts the convergence time from seconds to fractions of a second.
It does this by renegotiating port roles faster. It doesn’t wait for timeouts. It talks. It decides. It acts.
Which One Should You Use?
If you’re building a modern network, you don’t use basic STP. You use RSTP. Or its cousin, Multiple Spanning Tree Protocol (MSTP), which lets you run different spanning trees for different VLANs.
Why?
Because you might want Voice VLANs to take a different path than Data VLANs. MSTP lets you balance that load. Or at least keep them out of each other’s way.
If you’re on Cisco gear, you’re probably looking at PVST+ (Per-VLAN Spanning Tree). It’s proprietary. It runs a separate STP instance for every single VLAN.
It’s heavy on CPU. But it gives you granular control.
The Bottom Line
Redundancy is non-negot
