Redundancy and Broadcast Storms
When we talked about bus and ring networks earlier, one issue was the possibility of a single point of failure. In a star or star-bus network, the point with the most potential for bringing all or part of the network down is the switch or hub. Look at the example below:
In this example, if either switch A or C fails, then the nodes connected to that particular switch are affected, but nodes at the other two switches can still communicate. However, if switch B fails, then the entire network is brought down. What if we add another segment to our network connecting switches A and C?
In this case, even if one of the switches fails, the network will continue. This provides redundancy, effectively eliminating the single point of failure.
But now we have a new problem. In the last section, you discovered how switches learn where the nodes are located. With all of the switches now connected in a loop, a packet from a node could quite possibly come to a switch from two different segments. For example, imagine that Node B is connected to Switch A, and needs to communicate with Node A on Segment B. Switch A does not know who Node A is, so it floods the packet.
The packet travels via Segment A or Segment C to the other two switches (B and C). Switch B will add Node B to the lookup table it maintains for Segment A, while Switch C will add it to the lookup table for Segment C. If neither switch has learned the address for Node A yet, they will flood Segment B looking for Node A. Each switch will take the packet sent by the other switch and flood it back out again immediately, since they still don't know who Node A is. Switch A will receive the packet from each segment and flood it back out on the other segment. This causes a broadcast storm as the packets are broadcast, received and rebroadcast by each switch, resulting in potentially severe network congestion.
Which brings us to spanning trees...