This is the first in a series of posts on Spanning tree, in this post I will be describing the need for Spanning Tree Protocol (STP) in modern LAN environments.  I will be concentrating on the main topics covered in the CCNA ICND 2 exam.

What is Spanning Tree Protocol and why do we need it?

In modern LAN networks availability and uptime are key for most business critical applications. To achieve the required availability and uptime on the network redundancy is required to avoid single points of failure.  In LAN switching networks this redundancy would cause loops if there is no Layer 2 method to prevent them.

Spanning Tree Protocol (STP) as defined by the IEEE in 802.1D prevents frames looping indefinitely in the Layer 2 network by intelligently choosing to block certain ports while forwarding on others.

STP intelligently blocks ports with two goals in mind:

1. All devices in a VLAN can send frames to all other devices in the same VLAN, i.e. STP does not block too many interfaces thereby cutting off some devices from receiving frames.
2. Frames have a short Life and do not loop around the network indefinitely.

STP prevents three main problems associated with frames looping indefinitely in the network:

1. Broadcast storms
2. MAC address table instability
3. Multiple copies of the same frame being delivered to the destination.

The next few sections cover each of the above topics in detail.

What is a broadcast storm?

Because of the way switches forward unknown unicast frames and broadcast frames redundancy on a Layer 2 network has the side effect of creating loops and broadcast storms.

You need to remember that a switch will flood broadcast and unicast packets that are not in the MAC address table (unknown unicast frames) out all interfaces in the VLAN except the interface that the packet was received on.

The following video by Hùng Trần gives an excellent visual representation of what is happening during a broadcast storm.

In the video if PC1 sent an ARP request looking for PC4’s MAC address SW2 would broadcast the frame out all interfaces in PC1’s VLAN (remember that an ARP request is sent as a broadcast), except the interface on which it was received.  SW1 and SW2 receive this broadcast frame and flood it out all their interfaces aswell. PC4 receives the frame, but the original broadcast frame is still looping around the network and will continue to do so until the loop is broken by wither remove one of the links or powering down one of the switches.

Because broadcast frames tend to generate more broadcast frames the problem is amplified with more and more broadcast frames being generated as the frames loop around the network creating a Snowball effect.

Each time a broadcast frame is received by a networking device, the device must process the frame in its CPU. Due to this fact broadcast storms eventually saturate not only bandwidth on the links but the CPU’s of the devices on the network.

Using GNS3 and the topology used in the video, I will demonstrate what happens with a single broadcast frame being sent onto a network with STP disabled.

Before any frames were sent onto the network the CPU’s on the switches were hardly used:

Switch 1:

Switch 2:

Switch 3:

Within a few seconds of trying to ping PC4 from PC1 we can see the results of a loop on the Layer 2 network by checking the CPU on the switch which has risen to 50% utilization in less than 30 seconds.

Also looking at one of the trunk interfaces on SW1 we can see how much traffic a single broadcast frame can cause on the network when it loops indefinitely:

What is MAC address table instability?

MAC address instability occurs when frames loop around the network causing the switches to continually update their MAC address tables.

Using the topology in the video and examining  the frame sent by PC1 we can see how this affects the MAC address table. PC1 has a MAC address of 0050.7966.6803, when SW2 receives the frame from PC1 it updates it MAC address table to indicate that 0050.7966.6803 is off of interface Ethernet 1/0.

Because this is a broadcast frame it is flooded to SW3. SW3 then floods the frame to SW1 which in turn floods the frame back to SW2 SW2 updates its MAC address table again to indicate that the source MAC is now learned off of interface Eth 0/1. Because of this the MAC address table is constantly changing and can point to the wrong interface which would cause frames to be incorrectly forwarded.

Multiple Copies of the same frame

Finally looping frames on the network will cause multiple copies of the same frame being received by the destination host. If we look at the ARP broadcast from PC1 to PC4, PC4 will receive this broadcast frame from SW1 after it was sent directly from SW2 to SW1. However SW1 will also receive a copy of the Broadcast from SW3 and also forward that frame to PC4. This can cause problems to applications running on the PC as well as increase the CPU load of the destination device.

How STP 802.1D prevents loops

Now that we have seen what happens on a network with no STP enabled and the effects these looping frames have on the network, how does STP prevent loops from happening?

STP prevents loops by intelligently placing each interface on a switch in either a forwarding or blocking state.

Interfaces in a forwarding state act as per normal, forwarding user data frames and learning source mac addresses received on the interfaces and updating their MAC address tables with those details.

Interfaces in a blocking state do not forward any frames other than STP frames. Interfaces in a blocking state can still receive frames but they do not process the frames, they simply ignore any user data frames they receive. Interfaces in a blocking state do not learn MAC addresses of any frames they receive either.

For example if we look at the topology used earlier, if STP blocked interface Eth 0/1 on SW2 all devices would still be able to receive the frame without it looping through the network:

Now any frames broadcast from SW2 would be flooded to SW3 out inter Eth 0/0 but not to SW1 out of interface Eth 0/1 as it is in a STP blocking state.

SW3 would flood the frame out all its interface except the one it received the frame on. So in our example SW3 only floods the frame out interface Eth 0/0 towards SW1.

SW1 would flood the frames out of interfaces Eth1/0 to PC4 and also out interface Eth 0/1 towards SW2, but as interface Eth 0/1 on SW2 is in STP blocking state SW2 will not process any frames received from SW1 on interface Eth0/1 which stops the loop in its tracks.

In my next few posts I will work through exactly how STP decides which interface to put into a blocking state as well as the configuration and verification steps for setting up STP on the network.