Latest

CCNA RnS Article #28: Why Spanning Tree Protocol?

CCNA RnS Article #28: Why Spanning Tree Protocol?

In this article, we are going to talk about why Spanning Tree Protocol, and what problem it solves. So, let’s start with an overview and background.


CCNA Basic Lab @www.thenetworkdna.com
Fig 1.1- CCNA Basic Lab @www.thenetworkdna.com

A well-designed campus network ensures high availability with redundant hardware and links in place. The idea of having multiple links and devices is to make sure the network is available even if there is a hardware or link problem.

Let’s review a network setup in Figure 1, consider a connection between Core Switch 1 and Access Switch 1 (Link-1) goes down, User – 1 will be isolated from the network and will not be able to access files stored in File Server and communicate to User – 2. We can see this network is not highly available network.

Figure 1: Network Setup with no Highly Availability

Now, let’s see an improved version of the same network with additional links and hardware that makes this network a reliable and highly available setup.

Figure 2: Highly Available Network with Redundancy

It is good to have redundant components and connections to ensure high availability. In the above network setup, any link or a core switch failure in our network will not break the communication between the hosts and the fileserver.

We’ll see how adding redundant connections brings some of the serious problems in the network and how STP can solve those problems. STP allows Ethernet networks to have the benefits of having redundant connections and eliminate the side effects of adding extra links.

IEEE standardized the STP protocol as part of the IEEE 802.1d standard in 1990. Later RSTP standard 802.1w was released as an amendment to the original standard. However, in 2004 this improved version is integrated into the original standard (802.1d).

Issues in Redundant Paths/Link Network 

Adding redundant links to the network can cause a network loop where packets circle around the network infinitely – this is called a broadcast storm. Without a loop prevention mechanism like STP/RSTP, the broadcast storm can bring a network to its knee.

Figure 3: Broadcast Storm Situation

Figure 3 shows how broadcast storms are formed in a network with redundant paths. Let’s say PC-1 sends a broadcast frame and switch 1 receives the broadcast frame. According to the switching logic, flood the broadcast or unknown unicast packet to other ports except the one on which it was received. So Switch 1 floods the frame out of fa0/1 and fa0/0 ports connected to Switch 2 and 3 respectively.

Switch 2 receives the frame from Switch 1 and as per the switching logic, it will create a copy of the frame and forward it to Switch 3.

Notice, Switch 3 receives a copy of the same broadcast frame twice one from Switch 1 and the other from Switch 2. There is no exception it floods the frame out of other ports except the one it received on. And if you follow the frame flooding and forwarding you can say that this travels endlessly in our topology – this is called the broadcast storm scenario. And this keeps continuing until something happens that breaks the loop in a network like – reload of one switch or a link failure between any of the switches.

So this is the first problem STP/RSTP solves in a network with redundant paths. There is another problem that is solved by STP is “MAC Table instability”.

MAC Table Instability

In fact, this is the side effect of broadcast storms. In a MAC table instability situation, the ARP table or MAC table keeps changing because the frame with the same source MAC address arrives on different ports. For Instance, a copy of the same broadcast frame received by Switch 1 and Switch 2.

Figure 4: MAC table instability

Let’s try to understand this. Let’s say when the network was converged and working fine, Switch 1 MAC table entry for PC 1 was like this –

PC-1      fa0/2     VLAN 1

Now follow the frame, it reached to switch 2 to switch 3 and back to switch 1. Switch 1 gets an update saying PC1 is on interface fa0/0. Switch 1 updates the MAC table as below –

PC-1      fa0/0     VLAN 1

At this point, switch 1 cannot correctly deliver the frame to PC-1. For example, Switch 1 receives a frame for PC-1 (let’s say it’s a different frame other than the broadcast frame), and Switch 1 forwards the packet to the fa0/0 port which will go to Switch 3. This MAC table instability is causing more problems in the network – unnecessary congestion.

Last but not least, this broadcast storm situation also creates a problem where a host receives multiple copies of the frame. Once a destination receives the duplicate frames it gets confused and is not able to send return traffic. This causes an application failure.  

In summary, there are 3 main problems [broadcast storm, MAC table instability, and Multiple frames] that are common in a network with redundant links/paths without any loop prevention mechanism like STP/RSTP. I hope you find this informative. In our next article, we’ll see how STP prevents the broadcast storm.

 Continue Reading...