Majorbacon's Breakdown on Spanning Tree Protocol and Variants Part 1: The Problem

First, the Problem

Spanning Tree Protocol is one answer to a specific problem that occurs at a layer 1 & 2 levels - redundant connections between switches cause problems!

No Redundancy, No Problems



Now we've added a redundant connection enabling multiple paths for switch to switch communication

If a broadcast is sent out it will flood normally, but it will eventually also enter through the "back door" of the original switch that forwarded the broadcast, acting like a "new" message that needs further flooding, causing infinite flooding (remember this is layer 2, there is no time to live on a frame)

Worse yet, the broadcast actually went out both directions at the beginning of the flood, which means we actually have two broadcasts circulating the network infinitely!

The results of the unmanaged switching loop includes:

• Broadcast storms - no room for valid traffic - packets will keep getting forwarded until the switches run out of memory and start dropping frames.
  
• MAC Table Instability - remember that the source MAC address of a packet is used to update the switch's MAC address table - this means that eventually the first switch, the one connected to the broadcasting Server, will eventually believe that the server is attached to one of the other switches, since it will receive a broadcast from them with the Server's MAC address listed at the source. The switch will lose track of its own devices!
  
• Redundant Frames - both broadcasts and unicasts may be received multiple times by destination endpoints, bogging down intermediate services like TCP and higher level application services

So now we know the problem... see the Spanning Tree Protocol and Variants Part 2 to start seeing the solution!