Link redundancy and the need for Spanning-Tree (STP)
The need for redundant links
Switches are often connected to each other to extend broadcast domains across multiple devices. VLANs segment broadcast domains, so if you want the same VLAN to exist on more than one switch, you connect the switches together.
In the previous chapter, you learned that trunk links carry multiple VLANs over a single physical link. Trunk ports tag frames so the switch on the other end can identify which VLAN each frame belongs to.
A network engineer also has to plan for failures. In this case, the key question is:
- What happens if the trunk link between two switches fails, breaks, or gets disconnected?
Take the scenario below: Switch 1 and Switch 2 are connected by a single trunk link, and both switches have hosts connected. If that trunk link fails, hosts on one switch can no longer communicate with hosts on the other.
(Image 047)
Image Title - Trunk link between Switch 1 and Switch 2 fails
In a production network, mission-critical traffic may be using that trunk link. If it goes down, you can end up with an outage that costs the organization money until the issue is resolved.
This risk is even higher when the link is a long fiber run - across multiple floors, between buildings, or through underground conduit. If the cable is damaged, replacement can take days or weeks, especially if a third-party vendor is needed.
A straightforward solution is to add a second trunk link between the switches. With two links, if one fails, the other can continue forwarding frames between the switches.
(Image 048)
Image Title - Redundant Trunk links between Switch 1 and Switch 2
It’s unlikely that both links fail at the same time. Still, resilient network design is always a balance between redundancy and cost, and each organization has to decide how much risk it can accept.
Adding a second trunk link sounds simple: run another cable and configure both ports as trunk ports. But there’s an important side effect you must consider.
Switching loops and broadcast storms
Let’s look at a scenario where PC A is connected to Switch 1 and PC B is connected to Switch 2. The switches are connected using redundant trunk links.
(Image 049)
Image Title - PC A and PC B connected to Switch 1 and Switch 2 respectively with redundant links
Let’s say PC A wants to ping PC B. Assuming that PC A has never communicated with PC B before, what is the first thing that PC A would need to do before it can send a Ping Echo Request to PC B?
Send an ARP Request to PC B in order learn the MAC Address associated with PC B’s IP Address
Once Switch 1 receives the ARP Request from PC A, it will learn the Source MAC Address listed in the Frame, which is PC A’s MAC Address and then, it will look at the Destination MAC Address field of the Frame and see: “FF:FF:FF:FF:FF:FF”, meaning that this is a Broadcast Frame, which causes the Switch to do what?
Make copies of the Frame and flood them out of every port on the Switch within the same originating VLAN, except the port upon which the Frame was received
(Image 050)
Image Title - ARP Request Frame from PC A being forwarded to Switch 2
When Switch 2 receives the ARP Request frame from PC A, it learns PC A’s MAC address from the trunk port it arrived on and stores that entry in its MAC address table. Because the destination MAC is a broadcast address, Switch 2 floods the frame out every port in the originating VLAN, except the port it was received on. As a result, PC B receives the ARP Request.
(Image 051)
Image Title - PC B receiving the ARP Request, but it loops back to Switch 1
Here’s the critical detail: depending on timing, Switch 2 may receive the broadcast frame on one trunk link first. Since it did not receive the frame on the other trunk link, the “don’t send it back out the incoming port” rule doesn’t prevent Switch 2 from flooding the same broadcast frame out the second trunk link (GigabitEthernet 0/24) back to Switch 1.
When Switch 1 receives the same frame it originally sent, it updates its MAC address table and may now associate PC A’s MAC address with the trunk link instead of the access port where PC A actually resides. Then, because it’s still a broadcast frame, Switch 1 floods it again out every port except the port it was received on - sending yet another copy toward Switch 2.
That means PC A can receive a duplicate copy of its own frame, and the frame continues looping between the switches.
(Image 052)
Image Title - Switch 1 flooding the Broadcast Frame and looping it back over to Switch 2
This cycle continues ad infinitum unless the loop is broken (for example, by unplugging one of the redundant links). This condition is called a Switching Loop, also known as a “Layer 2 Loop”.
As the loop continues, broadcast frames multiply and consume more and more bandwidth and switch resources. Over time - especially as additional broadcast traffic is introduced - this can become a Broadcast Storm.
A broadcast storm can bring the network to a crawl and make switches and connected devices effectively unusable. Switch CPUs and forwarding resources get overwhelmed processing and replicating broadcast frames. Even if hosts are segmented into separate VLANs, other VLANs can still be impacted because:
- The switches are too busy copying and forwarding the looping broadcast frames to handle normal traffic.
- The trunk links can become oversaturated, preventing other frames from getting through.
This was a major problem until a protocol was created to solve it. Redundant links help prevent outages when a link fails, but with default switching behavior, redundancy can also create Layer 2 loops.
However, in the next chapter, we will discuss the protocol that is the solution to this problem.