Spanning Tree Introduction: Switching Loops

Redundancy is an important feature built into many network designs. Without redundant devices, connections, and power sources, a loss of service on any one device or connection can cause widespread disruptions. This is especially important in data center and campus designs where disruptions are not well tolerated.

When it comes to routing, protocols like EIGRP and OSPF benefit from redundant paths by load balancing traffic dynamically across multiple links. Traditional switching is a different story. Switches running Spanning Tree Protocol make sure the redundant links are available in the event that primary path fails, but do not use more than one path between any two hosts.

The single path distinction is a loop-prevention feature of Spanning Tree Protocol. Spanning Tree Protocol (or STP) is defined by IEEE 802.1d and has grown into many different flavors and iterations. Understanding how it operates is fundamental to operating modern Ethernet networks.

Switching Loop Example

Before we get into how Spanning Tree prevents loops from forming, it is important to understand why it’s needed in the first place. What would happen in broadcast networks like Ethernet without STP?

Switching Loop Diagram

The diagram above shows a simple redundant switch topology with HostA connected to SW1 and HostB connected to SW2. Let’s also assume that both hosts have just been added to the switches, so neither switch knows the MAC address of HostA or HostB.

If HostA were to try to send a frame to HostB, the frame will first enter interface Gig 0/24 of SW1. SW1 will not have a record of HostB’s MAC address, so it will flood the frame out all its ports (0/1, 0/2) except the port the frame it was received on (0/24). SW2 will receive the frame on both Gig 0/1 and 0/2 with HostA’s MAC address as the source.

This is where a loop has now formed if Spanning Tree is not running.

SW1 initially learned HostA’s MAC address on Gig 0/24, but now it is receiving the same frame on Gig 0/1 (looped from SW2, who also flooded the frame since it had not yet learned of HostB’s MAC address). SW1 will then update its MAC address table listing to port 0/1 and reflood the frame. The process continues endlessly, creating what we call a switch or bridging loop.

This results in some or all frames not reaching their destination. This is a simple example using an unknown unicast frame, but this scenario amplifies as more links and switches are added to the topology. Broadcast storms are particularly dangerous in a switch topology with redundant links since they are designed to be flooded out all ports. Many broadcast services will rebroadcast frames into the switches if they don’t receive a response, only exacerbating the problem.

Very quickly, switch CPU utilization will spike along with the ever-increasing bandwidth on all switch links. The end result is a total network meltdown until the loop is broken.

Author Aaron

Aaron knows networks. He's been involved in building and supporting world-class data networks for the past 10 years - from international cloud service providers to Fortune 50 data centers. Aaron consults independently and is focused on building the best training platform available.

More posts by Aaron

Leave a Reply