This is an example of STP doing what it does best, and that is putting the Amber lit port 2 in “Blocking” state, to prevent a Switching Loop from forming. This is the logical Topology for a better idea of what’s plugged into what:
This post is focused on the “original” STP, all the fundamentals / behaviors / defaults will be covered in this post, there will be minimal CLI output samples.
Spanning Tree Protocol Fundamentals
Layer 2 utilizes the 802.1d Spanning-Tree algorithm to find the best possible / lowest Cost paths in the switched network to Forward traffic, while also detecting possible network loops, and set least favorable paths in the network to Block traffic from being forwarded which prevents switching loops from forming.
Spanning-Tree Protocol works by switches generating BPDU’s (Bridge Protocol Data Unit) to both elect a “Root Bridge” by certain criteria on each individual switch, and once the Root Bridge is elected (or manually configured) BPDU’s then drive the STP algorithm to put redundant links either into Forwarding or Blocking state.
STP’s switching loop (sometimes called bridging loop) prevention is needed for the behavior of how switches flood frames, as in the “Forward / Flood / Filter” decision from the very beginning of switching fundamentals, and how the switch builds the MAC table.
The particular cause of the switching loop is demonstrated in this example, assuming this is a brand new network topology, and all MAC tables are empty on the switches:
The following sequence of events will lead to a switching loop of frame flooding, when Host A sends a Frame destined for Host D that is transmitted over shared medium on both sides of the switches and they are all connected to this shared medium:
1. All switches receive a copy of Frame destined for Host D, they first check the Source MAC which is not present in the MAC table, so an entry is added for Host A off the interface to Host A’s shared medium
2. All switches then look at the Destination MAC for Host D which is also missing from the MAC table, so they flood an Unknown Unicast Frame out of all interfaces except the interface the Frame came in on – In this case onto Host D’s shared medium
3. All switches receive a copy of these Unknown Unicast Frames, and again check the Source MAC first, which has Host A as the source now being learned on Host D’s side of the LAN via the shared Medium, and update the MAC table showing Host A is on Host D’s side of the LAN
4. They then look at the Destination MAC which has not yet been learned by the switch, so it then Floods the Unknown Unicast Frame again off Host A’s side of the LAN which will have all switches again updating the MAC table to reflect Host A now back on it’s side of the LAN
5. This behavior will loop continuously, not immediately pegging the network, but will slow it down gradually as the flooding uses more and more bandwidth / CPU resources until the network goes from slow to grinding to a halt from this flooding behavior
Spanning-Tree prevents this by running the STP algorithm to identify link redundancy, and putting the least desirable paths into Blocking State, so they will not participate in this Frame Flooding behavior.
Root Bridge Election and Bridge ID’s (BID’s) role in the election process
At the very beginning of a Root Bridge election, every switch advertises itself as the Root Bridge by sending out BIDs (Bridge Priority + MAC Address), which is carried by a type of traffic called BPDUs.
Once a Root Bridge is elected, it will be the only one originating BPDUs to the network every 2 seconds by default (the STP Hello Timer), to constantly tell the STP network it is the Root Bridge.
The BID is comprised of the “Bridge ID Priority” in this output, along with the MAC Address, and the lowest Priority + MAC Address will win the Root Election and is considered the “Superior BPDU” shown here:
SW1#sh span
VLAN0001
Spanning tree enabled protocol ieee
Root ID Priority 32769
Address 0017.5aa8.a600
Cost 19
Port 6 (FastEthernet1/0/4)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 1ce6.c7c1.c800
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
——————- —- — ——— ——– ——————————–
Fa1/0/1 Desg FWD 19 128.3 P2p
Fa1/0/4 Root FWD 19 128.6 P2p
SW1#
Highlighted in red are the values that make up a Bridges BID, that being the Bridge ID Priority + MAC Address (format below), and the value in parenthesis is the STP Priority + the sys-id-ext # which correlates to the VLAN # – This gives us the Bridge ID of 32769 as it is the default STP Priority of 32768 + 1 for the sys-id-ext for VLAN 1.
Much, much more about this is covered in my Port Selection post.
Highlighted in blue is demonstrating that the top value of “Root ID” is the Root Bridges “Bridge ID” information, or its BID. Below that the “Bridge ID” is the local switches BID information.
Highlighted at the bottom of the “sh span” output is the STP interface information including Role / current State / Priority Number / Link Type.
The BID is sent as a combination of both the local switches Bridge Priority value, which can be manually changed to “rig” the Root Bridge election, and is a combination of the 2-byte bridge Priority value combined with the 6-byte switch MAC address (so 8-bytes total) sent in the following format:
Bid format: 32769:0017.5aa8.a600
(The exact formatting of BID fields is also reviewed in Port Selection post for STP)
The Priority value is the first consideration of the BID, so it will be in front, followed by the MAC address to serve as a tie breaker behind it. To influence which switch is elected Root Bridge, the Priority can be changed on the switch desired to be the root, as the MAC address cannot be changed.
*** Important note on the Election Process ***
The election never really fully ends as BDPU’s are constantly being generated ever 2 seconds, and if a new switch is plugged into the network with Superior BID (lower Priority or MAC) than the current Root Bridge, it will trigger a Topology Change Notification and become the Root Bridge. It will then begin to originate BPDUs itself once it is the Root Bridge again every 2 seconds!
The 2 different types of BPDU’s, and what they are used for
There are two types of BPDU’s for 802.1D STP, for the purpose of the election I will focus on the “Configuration BPDU”, however here is a quick note on all three of them:
- Configuration BPDU (CBPDU) – Only originates from the Root Bridge once elected, provides information to all non-Root bridges (switches) such as STP timers, along with calculating STP values by running the STA (Spanning-Tree Algorithm) to detect any possible loops, come up with Root Path costs (cost from remote switch to Root), etc.
- Topology Change Notification BPDU (TCN) – Triggered by any detected change in the network on the switch, creates the TCN BPDU and sends it to neighbor switches
By default BPDU’s are generated every 2 seconds for rapid convergence, and a multicast to the “well known” MAC address 01:80:C2:00:00:00
802.1d STP Port States, and their behaviors during the Root Bridge Election
There is quite a few that are important to be very clear on, so I’ll bullet point them:
- Blocking state – Ports are put into Blocking state during the Root Bridge Election, if a better path to the Root Bridge is learned, or if it is not a Designated or Root port. Ports in blocking state DO NOT forward and actually discard incoming Frames, but listens and processes BPDU’s – It remains in this state for 20 seconds before moving into a “Listening” state (during the Root Bridge election)
- Listening state – Root and Designated ports will go into “Listening” state after the initial blocking state (all non-root / designated ports will stay in “Blocking” state), discarding frames from its local network segment as well as Frames received for forwarding, the switch is only “Listening” for BPDU’s and processing the information they contain. After 15 seconds, it moves into the “Learning” state
- Learning state – The port still is not forwarding Frames, but is processing the Frames without forwarding them to build its MAC table, also still listens for and processes incoming BPDU’s
- Forwarding state – The port is now Forwarding frames on to their destinations, while still processing Frames to keep the MAC table updated and processing BPDU’s
- Disabled state – Does not forward or participate in STP, considered to be a non-functioning port
One important and for me hard to understand state was Blocking mode, because I could not figure out how to observe this behavior, was actually seeing via debug an interface being placed into a Blocking state during a transition into a Forwarding state.
The 20 seconds of the 50 second transition time from Blocking to Forwarding actually refers to the max-age timer expiring (20 seconds by default), followed by 2 forward delay timers (15 seconds for Listening and Learning), but during that 20 seconds the port just does not come out of Blocking state – It is not PLACED into a Blocking state!
The max-age timer only comes into play under very certain circumstances, and I encourage you to read more on a thread I created on Cisco’s CCNP Forums:
Under what circumstance the STP Max-Age timer is used for Port Transitions
STP interface “Roles” that correlate with the states or states described above
- Root (Root) – This role indicates it is the Root Port, or the best path back to the Root Bridge, will be in Forwarding (FWD) state
- Designated (Desg) – This role indicates the port is not the Root Port, but is a valid loop-free path to Forward frames, will be in Forwarding (FWD) state
- Alternate (Altn) – This Role is used for interfaces with a state of either Blocking or Disabled (BLK) state
And that is all I got on the topic of STP Fundamentals!
Next up will be reviewing different Costs associated with STP and Link Speeds, some debugging of these port transitions, along with several different ways to identify a Root Bridge or non-Root Bridge for exam day!
The DEVNET GRIND! 