CCNA: Spanning Tree Protocol — STP, RSTP, and Why Layer 2 Loops Are Catastrophic
Spanning Tree Protocol is one of those topics where the exam question seems simple — “which port is blocking?” — but the underlying mechanics are subtle enough to bite you years into your career. STP was designed in 1985 by Radia Perlman at Digital Equipment Corporation and standardized as IEEE 802.1D in 1990. The problem it solves predates Ethernet as we know it today, and the solution it applies is elegant in a way that requires careful unpacking to fully appreciate. This guide covers everything from the fundamental loop problem through modern RSTP rapid convergence, with the Cisco IOS commands you need to configure and troubleshoot it in production.
Why STP Exists: The Layer 2 Loop Problem
The Fundamental Difference Between L2 and L3
IP routing stops loops through the Time to Live (TTL) field. Every IP packet carries a TTL value — 64, 128, or 255 are common defaults. Each router that forwards the packet decrements the TTL by one. When TTL reaches zero, the router drops the packet and sends an ICMP Time Exceeded message back to the source. This mechanism guarantees that even if a routing loop forms, packets cannot circulate forever. They die after at most 255 hops.
Ethernet frames have no such field. There is no hop count, no expiration timer, no mechanism that causes a switch to drop a frame after it has been forwarded too many times. A switch’s job is to flood frames it does not know how to deliver, and to forward frames it does. If the topology contains a loop, frames will simply circulate around that loop indefinitely — or, more precisely, they will multiply and circulate until the network collapses.
This is not a design flaw in Ethernet. The protocol was designed for simple, flat topologies where loops would not exist. The redundant topologies that real networks require came later, and with them came the need for STP.
What Happens Without STP: A Concrete Scenario
Consider two switches, SW-A and SW-B, connected by two cables — one as the primary link and one as a backup that an engineer added for redundancy without understanding STP. Both cables are active because STP is either disabled or misconfigured.
SW-A
/ \
link1/ \link2
/ \
SW-B------SW-B
More precisely:
+--------+ link1 +--------+
| SW-A |---------| SW-B |
| | link2 | |
| |---------| (same) |
+--------+ +--------+
Now a host connected to SW-A sends a broadcast frame — an ARP request, for example. A broadcast frame has the destination MAC address FF:FF:FF:FF:FF:FF. SW-A receives it on the host-facing port and floods it out all other ports, including both link1 and link2.
SW-B receives the same broadcast twice — once on link1 and once on link2. Because it is a broadcast, SW-B floods each copy out all its other ports. The copy that arrived via link1 gets flooded back to SW-A via link2. The copy that arrived via link2 gets flooded back to SW-A via link1. SW-A now receives two copies of a broadcast it originated — and since they are broadcasts, it floods them again. The cycle repeats and accelerates.
Within milliseconds, you have a broadcast storm: an exponentially growing flood of frames consuming all available bandwidth and switch CPU cycles. A gigabit link saturates completely. The switches’ CPUs spend all their time processing frames in the interrupt handler and can no longer respond to management traffic, spanning-tree BPDUs, or anything else. The network becomes completely unusable.
Three Distinct Problems Caused by Loops
The broadcast storm is the most visible symptom, but Layer 2 loops cause three distinct failure modes, each worth understanding separately.
Broadcast Storm. As described above: a single broadcast frame spawns exponentially more copies on each traversal of the loop. The traffic volume grows without bound until the physical medium is saturated. On a 1 Gbps link, a loop can drive the link to 100% utilization within seconds of an initial broadcast. All traffic — including management, routing protocol hellos, STP BPDUs — is starved out. In practice, this is what kills the network.
MAC Table Instability. A switch builds its CAM (Content Addressable Memory) table by examining the source MAC address of incoming frames and recording which port that MAC was learned on. With a loop, the same frame arrives at a switch from multiple directions. The switch sees the same source MAC arriving on port 1, then on port 2, then on port 1 again — updating the table with each arrival. The MAC table entry for that address flips back and forth with each loop iteration. A switch experiencing this will log %SW_MATM-4-MACFLAP_NOTIF: Host <mac> in vlan <id> is flapping between port <X> and port <Y> continuously. Under load this represents thousands of table updates per second, consuming CPU and memory.
Duplicate Frame Delivery. Unicast frames can also loop. If a host’s MAC is not yet in the CAM table, the switch floods the unicast frame just as it would a broadcast. That frame traverses the loop and arrives at the destination multiple times. For stateless protocols, this merely wastes bandwidth. For stateful applications, receiving the same TCP segment twice may be harmless (TCP handles duplicates) but receiving the same application-layer message twice can cause data corruption or transaction duplication depending on the application. Financial systems, database replication, and storage protocols are particularly vulnerable.
Why You Cannot Just “Be Careful”
The intuitive response is to simply not create loops — don’t connect two cables between the same pair of switches. In practice this is impossible to maintain for several reasons. Network teams add redundant links to protect against link failures. Different teams may manage different parts of the network without coordination. Hosts can be connected to multiple switches through docking stations or dual NICs. A user can bring in an unmanaged switch and connect it to two wall ports that happen to back-haul to the same closet switch. STP is not a best practice for avoiding loops — it is the mandatory mechanism that makes redundant topologies safe to operate.
IEEE 802.1D STP: Fundamentals and Algorithm Overview
Bridge Protocol Data Units (BPDUs)
STP switches communicate using Bridge Protocol Data Units (BPDUs). A BPDU is a special Ethernet frame sent to the multicast MAC address 01:80:C2:00:00:00 (the STP multicast address). Every switch that participates in STP sends and processes BPDUs. Switches that have STP disabled ignore them entirely, which is one reason STP disabled on a switch connected to an STP network can be dangerous.
There are two types of BPDUs:
Configuration BPDUs are the primary STP control messages. They are generated by the root bridge and propagated throughout the network. Every non-root switch that receives a configuration BPDU relays a modified version out its designated ports. A configuration BPDU contains:
| Field | Size | Description |
|---|---|---|
| Protocol ID | 2 bytes | Always 0x0000 for STP |
| Version | 1 byte | 0x00 for 802.1D, 0x02 for RSTP |
| Message Type | 1 byte | 0x00 = configuration BPDU |
| Flags | 1 byte | TC and TCA bits |
| Root Bridge ID | 8 bytes | Bridge ID of the current root |
| Root Path Cost | 4 bytes | Cost from sender to root |
| Sender Bridge ID | 8 bytes | Bridge ID of the sending switch |
| Port ID | 2 bytes | Port on the sending switch |
| Message Age | 2 bytes | How long since root generated the BPDU |
| Max Age | 2 bytes | Maximum age before BPDU is discarded |
| Hello Time | 2 bytes | Interval between root’s configuration BPDUs |
| Forward Delay | 2 bytes | Duration of Listening and Learning states |
Topology Change Notification (TCN) BPDUs are sent by a non-root switch toward the root bridge to signal that a topology change has occurred. They trigger a network-wide MAC table flush process described in detail in the topology changes section below.
Configuration BPDUs are sent by the root bridge every Hello Time (default 2 seconds). Non-root switches relay BPDUs out their designated ports but do not generate their own — they propagate the root’s BPDU with the Message Age incremented and their own Bridge ID substituted in the Sender Bridge ID field.
The Four-Step Election Process
STP topology determination proceeds in four logically ordered steps. These happen concurrently during initial convergence, but understanding them sequentially is essential for correctly reasoning about which ports will block.
Step 1: Elect the Root Bridge
Every switch begins believing it is the root bridge. Each switch sends configuration BPDUs advertising itself as the root. When a switch receives a BPDU with a lower Bridge ID than its own, it stops advertising itself as root and begins relaying the superior BPDU. The switch with the lowest Bridge ID across the entire network wins the election and becomes the root bridge.
The Bridge ID is 8 bytes:
- 2 bytes: bridge priority
- 6 bytes: MAC address of the switch
Default priority is 32768. If two switches have the same priority (very common in unconfigured networks), the tie is broken by MAC address — the lower MAC wins. This is why you must explicitly configure priorities: you have no control over which switch has the lowest MAC address, and the root bridge placement directly affects traffic paths.
The root bridge has all of its ports in the Designated Forwarding state. It is the logical center of the spanning tree.
Step 2: Elect Root Ports (One Per Non-Root Switch)
Every non-root switch must determine which of its ports provides the best path to the root bridge. That port becomes the Root Port (RP). There can be exactly one root port per non-root switch.
The best path is determined by root path cost: the cumulative cost of all links traversed to reach the root. Each link adds its port cost to the running total. The switch selects the port with the lowest cumulative cost to the root.
Tiebreakers applied in order when costs are equal:
- Lowest sender Bridge ID (the Bridge ID of the upstream switch advertising the BPDU)
- Lowest sender Port ID (the port ID on the upstream switch)
- Lowest local Port ID (the port on the local switch receiving the BPDU)
Step 3: Elect Designated Ports (One Per Segment)
Every network segment — every collision domain or switch port — must have exactly one Designated Port (DP). The designated port is the port on that segment that provides the best path to the root bridge, and it is the port that will forward traffic toward the root on that segment.
For segments directly connected to the root bridge, the root bridge’s port on that segment is always the designated port (it has a root path cost of 0).
For other segments, the switch with the lowest root path cost on that segment wins the designated port election. Tiebreakers are the same as for root port selection: lowest Bridge ID, then lowest Port ID.
Step 4: Block All Remaining Ports
Any port that is neither a root port nor a designated port becomes a Non-Designated Port and is placed in the Blocking state. This is where STP achieves its purpose: by blocking these ports, it eliminates all loops while preserving at least one active path between any two points in the network.
Bridge ID in Detail: Priority, MAC Address, and Extended System ID
Classic Bridge ID Structure
The classic 802.1D Bridge ID is straightforward:
+------------------+---------------------------+
| Priority (2B) | MAC Address (6B) |
| default 32768 | switch base MAC |
+------------------+---------------------------+
<--- 8 bytes total ---------------------------->
Priority is configurable in increments of 4096, ranging from 0 to 61440. The valid values are therefore: 0, 4096, 8192, 12288, 16384, 20480, 24576, 28672, 32768, 36864, 40960, 45056, 49152, 53248, 57344, 61440.
Extended System ID (802.1t)
Modern Cisco switches run PVST+, which requires a separate spanning tree instance per VLAN. If you tried to run classical 802.1D, every switch in every VLAN would compete using the same Bridge ID, making cross-VLAN load balancing impossible. The Extended System ID modification (802.1t, now incorporated into 802.1D-2004) solves this by embedding the VLAN ID into the Bridge ID.
The 2-byte priority field is split:
+--------+----+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
| bit 15 | 14 | 13 | 12 | 11 | 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
+--------+----+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
| Bridge Priority (4 bits, multiples of 4096) | Extended System ID / VLAN ID (12 bits) |
+--------+----+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+--------+
The upper 4 bits remain the configurable priority (in multiples of 4096). The lower 12 bits are automatically populated with the VLAN ID. This means:
- The effective Bridge ID priority = configured priority + VLAN ID
- For VLAN 10 with default priority 32768: effective priority = 32768 + 10 = 32778
- For VLAN 100 with default priority 32768: effective priority = 32768 + 100 = 32868
This is why on Cisco switches show spanning-tree vlan 10 shows the bridge priority as 32778, not 32768. The 10 is the VLAN ID baked in. When you configure priority, you must specify the base value (a multiple of 4096), not the effective value.
SW-A(config)# spanning-tree vlan 10 priority 4096
! Effective priority for VLAN 10 = 4096 + 10 = 4106
! This switch will win the root election for VLAN 10 against any switch
! still at default priority 32778
Port Costs: Original, Revised, and Long Mode
Why Port Cost Matters
Root port and designated port elections depend on root path cost — the sum of port costs along the path to the root. The port cost assigned to each link must reflect the relative desirability of using that link. A 10 Gbps link should be preferred over a 1 Gbps link, and port costs encode this preference.
Original 802.1D Costs
The original 1998 802.1D specification defined these costs:
| Link Speed | Port Cost |
|---|---|
| 10 Mbps | 100 |
| 100 Mbps | 19 |
| 1 Gbps | 4 |
| 10 Gbps | 2 |
These values work for the speeds that existed in the 1990s but break down for modern networks. A 10 Gbps link and a 100 Gbps link both have values that cannot be differentiated with the original scale — they simply run out of resolution. Both 10 Gbps and faster links would get cost 2 (the minimum meaningful value), making STP unable to distinguish between them.
Long Mode Costs (IEEE 802.1t / Revised)
The long-mode cost table was introduced to accommodate higher link speeds:
| Link Speed | Long-Mode Cost |
|---|---|
| 10 Mbps | 2,000,000 |
| 100 Mbps | 200,000 |
| 1 Gbps | 20,000 |
| 10 Gbps | 2,000 |
| 100 Gbps | 200 |
| 1 Tbps | 20 |
Long mode uses a 32-bit cost field, allowing much finer differentiation across many orders of magnitude of link speed. For any network with 10 Gbps or faster links, long mode is strongly recommended.
SW-A(config)# spanning-tree pathcost method long
! Must be configured identically on all switches in the spanning tree
! Mismatched cost methods between switches cause unpredictable behavior
Overriding Port Cost Per-Interface
Sometimes you want to manually influence path selection — for example, to prefer a 1 Gbps fiber link over a 1 Gbps copper link even though their auto-detected costs are identical:
SW-A(config)# interface GigabitEthernet0/1
SW-A(config-if)# spanning-tree cost 3
! Lower cost makes this port more preferred for root port election
! Applies to all VLANs on this port unless you specify a VLAN
SW-A(config-if)# spanning-tree vlan 10 cost 3
! VLAN-specific cost override (PVST+ only)
A manually configured cost overrides the automatic cost derived from interface speed. If the link speed changes (auto-negotiation, optic replacement), the manual cost remains unchanged — document this or it becomes a maintenance headache.
Port Roles in Detail
STP assigns each port one of four roles. Understanding the distinction between role and state is critical — role describes what the port does in the topology; state describes what traffic it processes.
Root Port (RP)
One root port per non-root switch. This is the port that provides the best path (lowest root path cost) to the root bridge. The root port is always in the Forwarding state. Traffic destined for the root bridge, or received from the root bridge, traverses the root port.
Designated Port (DP)
One designated port per network segment. On segments between two switches, exactly one switch wins the designated port election — that switch’s port on the segment is the designated port and stays Forwarding. The other switch’s port on the same segment loses and becomes Non-Designated (Blocking). On segments between a switch and an end host, the switch port is always the designated port because there is no competing switch.
Non-Designated Port (Alternate/Blocking)
Any port that is neither a root port nor a designated port. These ports are placed in the Blocking state to eliminate loops. They receive BPDUs (so they know when the topology changes and can take over if needed) but do not forward data frames and do not learn MAC addresses.
Disabled Port
A port that is administratively shut down (shutdown in IOS). It participates in no STP processing.
Tiebreaker Logic Applied in Order
When two ports have equal root path cost, the following tiebreakers determine which wins (for both root port and designated port elections):
- Lowest root path cost (primary criterion)
- Lowest sender Bridge ID — the Bridge ID of the switch sending the superior BPDU
- Lowest sender Port ID — on the upstream switch, the port with the lower Port ID wins. Port ID = 1-byte priority (default 128) + 1-byte port number. Default port priority is 128; you can change it with
spanning-tree port-priority. - Lowest local Port ID — used only for root port election when two ports on the same switch receive BPDUs from the same upstream switch (common with EtherChannel links if STP is not properly handled)
Understanding tiebreakers is essential for CCNA exam scenarios. A common exam question presents a four-switch topology and asks which port is blocking. You must trace the election process systematically.
The Three-Switch Election: Step-by-Step ASCII
Let us trace the complete election on a concrete three-switch topology. We will assign priorities and MAC addresses to make the election deterministic.
+----------+
| SW-ROOT |
| Pri: 4096|
| MAC: A1 |
+----+-----+
|Gi0/1
|
----------+----------
| |
Gi0/1 Gi0/1
+-------+ +-------+
| SW-B | | SW-C |
|Pri: | |Pri: |
|32768 | --Gi0/2---| 32768 |
|MAC: B2| Gi0/2 |MAC: C3|
+-------+ +-------+
Link costs (short mode, 1 Gbps = 4 everywhere):
SW-ROOT -- SW-B : cost 4 each direction
SW-ROOT -- SW-C : cost 4 each direction
SW-B -- SW-C : cost 4 each direction
Bridge IDs (VLAN 1, so effective priority = configured priority + 1):
SW-ROOT : priority 4096 + 1 = 4097, MAC A1:A1:A1:A1:A1:A1
SW-B : priority 32768 + 1 = 32769, MAC B2:B2:B2:B2:B2:B2
SW-C : priority 32768 + 1 = 32769, MAC C3:C3:C3:C3:C3:C3
Step 1: Root Bridge Election
All three switches begin sending BPDUs claiming to be root. Each evaluates received BPDUs:
- SW-B receives a BPDU from SW-ROOT with Bridge ID 4097/A1. This is lower than SW-B’s own 32769/B2. SW-B accepts SW-ROOT as root.
- SW-C receives a BPDU from SW-ROOT with Bridge ID 4097/A1. This is lower than SW-C’s own 32769/C3. SW-C accepts SW-ROOT as root.
- SW-B and SW-C also exchange BPDUs. SW-B’s Bridge ID (32769/B2) is lower than SW-C’s (32769/C3) because the MAC B2:B2… is lower than C3:C3… — but this is irrelevant because both already accepted SW-ROOT.
Result: SW-ROOT is the Root Bridge.
+----------+
| SW-ROOT | <-- ROOT BRIDGE (all ports DP)
| BID:4097 |
+----+-----+
|
----------+----------
| |
+-------+ +-------+
| SW-B | | SW-C |
|BID: | |BID: |
|32769 |-----------|32769 |
+-------+ +-------+
Step 2: Root Port Election (Non-Root Switches)
SW-B’s root port election:
- Gi0/1 (toward SW-ROOT): root path cost = 4 (one hop, cost 4)
- Gi0/2 (toward SW-C, then to SW-ROOT via SW-C): root path cost = 4 + 4 = 8
Gi0/1 wins. SW-B’s Root Port = Gi0/1
SW-C’s root port election:
- Gi0/1 (toward SW-ROOT): root path cost = 4
- Gi0/2 (toward SW-B, then to SW-ROOT via SW-B): root path cost = 4 + 4 = 8
Gi0/1 wins. SW-C’s Root Port = Gi0/1
+----------+
| SW-ROOT |
+--DP--DP--+
| |
(4) (4)
| |
RP--+-------+-------+--RP
| SW-B | | SW-C |
+-------+ +-------+
Gi0/2 --- Gi0/2
Step 3: Designated Port Election (Per Segment)
Segment: SW-ROOT – SW-B (link between them)
- SW-ROOT’s Gi0/1 on this segment: root path cost = 0 (it IS the root)
- SW-B’s Gi0/1 on this segment: root path cost = 4
SW-ROOT wins. Designated Port = SW-ROOT Gi0/1
Segment: SW-ROOT – SW-C (link between them)
- SW-ROOT’s Gi0/2 on this segment: root path cost = 0
- SW-C’s Gi0/1 on this segment: root path cost = 4
SW-ROOT wins. Designated Port = SW-ROOT Gi0/2
Segment: SW-B – SW-C (link between them)
- SW-B’s Gi0/2 on this segment: root path cost = 4 (SW-B can reach root in cost 4)
- SW-C’s Gi0/2 on this segment: root path cost = 4 (SW-C can also reach root in cost 4)
Costs are equal. Tiebreaker: lowest sender Bridge ID. SW-B has Bridge ID 32769/B2:B2…, SW-C has Bridge ID 32769/C3:C3… B2 < C3 numerically, so SW-B wins.
Designated Port = SW-B Gi0/2
Step 4: Remaining Ports Block
SW-C’s Gi0/2 is not a root port (SW-C’s RP is Gi0/1) and not a designated port (SW-B won that election). It becomes Non-Designated / Blocking.
Final Topology
+------------+
| SW-ROOT |
| Gi0/1=DP |
| Gi0/2=DP |
+--DP---DP---+
| |
(4) (4)
| |
RP=Gi0/1| |Gi0/1=RP
+--+--+ +--+--+
| SW-B| | SW-C|
| | | |
+--+--+ +--+--+
|Gi0/2=DP |Gi0/2=BLK
+----------+
(SW-B DP -- SW-C BLK)
Loop is broken. SW-C’s Gi0/2 is blocking. All traffic from SW-C to SW-B must traverse SW-ROOT. This is the cost of loop prevention with 802.1D STP — a redundant link exists but traffic must take the longer path. RSTP and PVST+ address this through rapid convergence and per-VLAN load balancing respectively.
Port States: 802.1D
802.1D defines five port states. A port transitions through these states in sequence on its way to Forwarding. Understanding the time spent in each state explains why 802.1D STP convergence is so slow.
| State | Receives BPDUs | Sends BPDUs | Learns MACs | Forwards Data | Duration |
|---|---|---|---|---|---|
| Disabled | No | No | No | No | Until enabled |
| Blocking | Yes | No | No | No | Up to Max Age (20s) |
| Listening | Yes | Yes | No | No | Forward Delay (15s) |
| Learning | Yes | Yes | Yes | No | Forward Delay (15s) |
| Forwarding | Yes | Yes | Yes | Yes | Until topology change |
State Descriptions
Blocking. A port enters Blocking either because it lost the designated port election (it is a non-designated port) or because it is a newly activated port waiting to determine its role. In Blocking, the port receives BPDUs to participate in the STP election but does not send them, does not learn MAC addresses, and does not forward data. If no superior BPDU is received within Max Age (20 seconds), the port transitions to Listening.
Listening. The port is actively participating in STP — sending and receiving BPDUs, participating in elections. No data frames are forwarded and no MAC addresses are learned. Duration: Forward Delay (15 seconds).
Learning. The port now populates the CAM table by examining source MAC addresses of received frames, but still does not forward data. This phase exists to prevent temporary black holes: when a port transitions to Forwarding, the switch already has a populated MAC table so it does not need to flood every unicast frame. Duration: Forward Delay (15 seconds).
Forwarding. Fully operational. The port sends and receives BPDUs, learns MACs, and forwards data frames.
Disabled. Administratively down. No STP processing occurs.
Port State Transition Diagram (802.1D)
link up
|
v
+------------------+
| BLOCKING |
| Recv BPDUs only |
| max 20s (MaxAge) |
+--------+---------+
|
selected as DP or RP
|
v
+------------------+
| LISTENING |
| Send/Recv BPDUs |
| no data, no MACs |
| 15s (FwdDelay) |
+--------+---------+
|
timer expires
|
v
+------------------+
| LEARNING |
| Send/Recv BPDUs |
| learn MACs |
| no data forward |
| 15s (FwdDelay) |
+--------+---------+
|
timer expires
|
v
+------------------+
| FORWARDING |
| fully operational|
+------------------+
Any state --> BLOCKING if superior BPDU received
Any state --> DISABLED if port shutdown
The 50-Second Problem
When a link fails and STP must reconverge, the sequence is:
- The failure is detected (immediate if physical link-down, up to 20 seconds via Max Age if the link stays up but a switch fails)
- Ports that were Blocking and need to transition to Forwarding must pass through Listening (15s) and Learning (15s)
- Total worst-case convergence: 20 + 15 + 15 = 50 seconds
During those 50 seconds, traffic on the affected paths is completely disrupted. For a single-site enterprise network, 50 seconds of downtime for any link failure is often unacceptable. For VOIP, video conferencing, or any real-time application, it is catastrophic. This was the primary motivation for developing RSTP.
The problem is compounded by indirect failures. If an intermediate switch fails and the physical link does not go down (the fiber is intact but the switch CPU hangs, for example), the detecting switch must wait a full Max Age (20 seconds) before declaring the BPDU stale and starting reconvergence. Only then do the 15+15 second timers begin.
STP Timers: Configuration and Constraints
The Three Core Timers
Hello Time (default: 2 seconds). The interval at which the root bridge generates and sends configuration BPDUs. Non-root switches relay BPDUs at the same interval. Reducing Hello Time provides faster failure detection but increases control plane overhead.
Max Age (default: 20 seconds). The maximum time a switch will retain a BPDU before discarding it as stale. If a switch does not receive a BPDU within Max Age, it assumes the upstream path has failed and begins reconvergence. This timer is the dominant contributor to slow convergence after indirect failures.
Forward Delay (default: 15 seconds). The duration of both the Listening and Learning states. Traffic is disrupted for 2 × Forward Delay after a port must transition from Blocking to Forwarding.
Timer Configuration
! Configure timers on the root bridge (they propagate via BPDUs to all switches)
SW-ROOT(config)# spanning-tree vlan 1 hello-time 2
SW-ROOT(config)# spanning-tree vlan 1 forward-time 15
SW-ROOT(config)# spanning-tree vlan 1 max-age 20
! The root bridge's timers are authoritative for the entire spanning tree
! Configure timers on non-root switches too, as failsafe if root changes
Timer Constraints (the IEEE Formula)
IEEE 802.1D specifies mathematical constraints on timer values to ensure STP stability. If timers are misconfigured, BPDUs can be discarded before they propagate through the topology, causing false reconvergence events.
The constraints are:
2 × (Forward Delay - 1) >= Max Age
Max Age >= 2 × (Hello Time + 1)
With defaults:
2 × (15 - 1) = 28 >= 20 (satisfied)
20 >= 2 × (2 + 1) = 6 (satisfied)
If you want to reduce Forward Delay to 10 seconds:
2 × (10 - 1) = 18 >= Max Age
So Max Age must be <= 18 seconds
Max Age >= 2 × (Hello Time + 1) = 2 × 3 = 6 seconds
Max Age = 14 seconds would satisfy both: 18 >= 14 >= 6
The Real Answer: Use RSTP
The correct response to slow STP convergence is not to tune timers. Aggressive timer tuning is fragile: it works in small topologies but causes instability in larger ones where BPDUs must traverse many hops. Each hop adds Message Age, and with a reduced Max Age, BPDUs from the far edge of the topology may be discarded before they reach their destination. This causes ports to think the root is unreachable and begin reconverging — making the problem worse.
The correct answer is to run Rapid STP (RSTP, IEEE 802.1w) or Cisco’s Rapid PVST+, which achieves sub-second convergence through a fundamentally different mechanism rather than timer tricks.
Topology Changes: TCN BPDUs and MAC Table Flushing
What Triggers a Topology Change
In 802.1D, a topology change occurs when:
- A port transitions from Blocking to Forwarding (a new path becomes active)
- A port transitions from Forwarding to Blocking (a path is lost)
When a non-root switch detects such a change, it sends a TCN BPDU (Topology Change Notification) out its root port toward the root bridge. The upstream switch receiving the TCN acknowledges it with a TCA (Topology Change Acknowledgment) flag set in the next configuration BPDU, and itself sends a TCN out its own root port. This process propagates the notification hop-by-hop toward the root.
What the Root Bridge Does with a TCN
When the root bridge receives a TCN, it sets the TC (Topology Change) flag in its configuration BPDUs for a period of Max Age + Forward Delay (20 + 15 = 35 seconds). All switches in the network receive these BPDUs with the TC flag set.
When a switch receives a configuration BPDU with TC set, it reduces its MAC address aging timer from the default 300 seconds down to Forward Delay (15 seconds). This aggressive aging causes the MAC table to flush entries rapidly — hosts need to re-learn paths through the new topology rather than being forwarded to the wrong port based on a stale CAM entry.
The Problem with 802.1D Topology Change Handling
The MAC table flush is blunt. Every switch in the entire spanning tree flushes all its MAC entries (except those that were recently learned). Even if the topology change occurred in one corner of the network and had no effect on paths elsewhere, the TC flag causes all switches to flush all entries. This results in a wave of unnecessary flooding across the network as every host re-learns its position, which temporarily increases bandwidth consumption and switch CPU load.
RSTP improves this significantly: TC notifications are more granular and MAC table flushing is targeted rather than network-wide.
Diagnosing Topology Changes
SW-A# show spanning-tree detail
VLAN0001 is executing the rstp compatible Spanning Tree protocol
Bridge Identifier has priority 32769, sysid 1, address aabb.cc00.0100
...
Number of topology changes 47 last change occurred 00:02:15 ago
from GigabitEthernet0/1
...
! High topology change count combined with recent occurrence time
! indicates instability -- investigate the port shown as the source
SW-A# show log | include TOPOLOGY
%SPANTREE-2-TOPOLOGY_CHANGE: Vlan 1 topology change detected on
GigabitEthernet0/1, propagating
A topology change count that keeps climbing is a warning sign. Common causes: a flapping link, a misconfigured end host sending BPDUs, a port lacking PortFast on an access port (hosts coming up and down generate TCs without PortFast), or a legitimate network instability.
RSTP: IEEE 802.1w
The Fundamental Difference
802.1D STP is timer-driven. Ports transition through states on a fixed schedule, regardless of whether neighboring switches are ready. The delays exist to guarantee that the old topology has fully aged out before the new one is activated — a conservative approach that prioritizes safety over speed.
RSTP is negotiation-driven. Instead of waiting for timers, switches use a handshake mechanism (the Proposal/Agreement exchange) to coordinate port state transitions. A switch does not open a port to forwarding until its downstream neighbor has explicitly agreed that it is safe to do so. Because the negotiation is explicit rather than timer-based, it completes in milliseconds rather than seconds.
New Port Roles in RSTP
RSTP introduces two additional port roles:
Alternate Port. A port that has a path to the root bridge but is not the best path — it is an alternative to the root port. An alternate port remains in the Discarding state but maintains an up-to-date view of the topology. If the root port fails, the alternate port can transition to Forwarding almost instantly — it already knows the path cost and does not need to wait for timers. This is the primary mechanism that makes RSTP recovery so fast.
Backup Port. A port on a segment where the same switch already has a designated port. This is uncommon — it occurs when a switch has two connections to the same shared segment (a hub, for example). The backup port provides redundancy for the designated port on that same segment. Backup ports are rare in modern switched networks.
Edge Port. A port connected to an end device (PC, printer, server). Because no BPDUs are expected from end devices, edge ports skip the STP negotiation process entirely and transition directly to Forwarding on link-up. This is the RSTP equivalent of Cisco’s PortFast.
New Port States in RSTP
RSTP collapses the five 802.1D states into three:
| RSTP State | 802.1D Equivalent | Description |
|---|---|---|
| Discarding | Blocking + Listening | Receives BPDUs, no data forwarding, no MAC learning |
| Learning | Learning | Learns MACs, no data forwarding |
| Forwarding | Forwarding | Fully operational |
The elimination of the Listening state is significant: the old Listening state existed to give BPDUs time to propagate so that every switch could agree on the topology before any port transitioned to Forwarding. RSTP’s Proposal/Agreement mechanism replaces this with explicit coordination, making the timed Listening phase unnecessary.
Port State Transition Diagrams: 802.1D vs RSTP
802.1D Port State Transitions:
================================
link up / port selected
|
v
[BLOCKING] <----- superior BPDU received (any state)
|
selected as RP or DP
|
v
[LISTENING] -- 15s Forward Delay --+
| |
v |
[LEARNING] -- 15s Forward Delay --+
|
v
[FORWARDING]
Worst case: 20s (MaxAge) + 15s (Listen) + 15s (Learn) = 50 seconds
RSTP Port State Transitions:
==============================
link up
|
+-- edge port? --> [FORWARDING] immediately
|
+-- non-edge port:
|
v
[DISCARDING]
|
Proposal/Agreement
handshake complete
|
v
[LEARNING] -- Learning timer --+
|
v
[FORWARDING]
Typical: < 1 second for P/A handshake + brief Learning
The Proposal/Agreement Handshake
When an RSTP switch detects a new link or recovers from a failure, it does not just wait for timers. Instead:
-
The upstream switch sends a BPDU with the Proposal flag set to the downstream switch. This says: “I would like to make my port toward you a Designated-Forwarding port.”
-
The downstream switch receives the Proposal. Before it can agree, it must ensure that no loops will form. It does this by placing all its non-edge, non-root ports into a Sync state (temporarily Discarding). Once all such ports are synced (either already Discarding, or forced to Discarding), the downstream switch is ready.
-
The downstream switch sends back a BPDU with the Agreement flag set. This says: “I agree. My root port toward you can transition to Forwarding.”
-
Both sides transition their respective ports to Forwarding simultaneously. No timer waiting required.
-
The downstream switch then initiates its own Proposal/Agreement process with its downstream neighbors, propagating the transition rapidly outward from the root.
This process completes end-to-end in the time it takes BPDUs to traverse the topology — typically milliseconds on a small network, under a second on a large campus.
Backward Compatibility with 802.1D
RSTP switches detect when they are connected to a legacy 802.1D switch by the BPDU version field. If an RSTP switch receives a legacy BPDU (version 0x00), it falls back to 802.1D behavior on that port — the 802.1D timers apply on that segment. This allows RSTP to be deployed incrementally, but be aware that any 802.1D switch in the topology will slow convergence on its connected segments to 802.1D speeds.
! Check RSTP/STP compatibility mode
SW-A# show spanning-tree vlan 1 detail | include compat
Bridge Identifier has priority 32769, sysid 1, address aabb.cc00.0100
Configured to use the rstp compatible Spanning Tree protocol
Cisco STP Implementations: PVST+, Rapid PVST+, and MST
PVST+ (Per-VLAN Spanning Tree Plus)
Standard 802.1D runs a single spanning tree instance for all VLANs. This means every VLAN shares the same topology — if port X is blocking for VLAN 1, it is blocking for all VLANs. This is inefficient: the blocked link is wasted capacity that could carry traffic for some VLANs while remaining blocked for others.
Cisco’s PVST+ runs a separate spanning tree instance for each VLAN. Each instance has its own root bridge election, its own port assignments, and its own blocked ports. This allows you to engineer different trees for different VLANs — making SW-A the root for VLAN 10 and SW-B the root for VLAN 20, thereby load-balancing traffic across redundant uplinks.
PVST+ uses IEEE 802.1Q trunking with Cisco-specific enhancements. It is the default STP mode on Cisco IOS switches and has been for many years.
Rapid PVST+
Rapid PVST+ is Cisco’s implementation of RSTP (802.1w) on a per-VLAN basis. It combines the topology flexibility of PVST+ with RSTP’s sub-second convergence. Rapid PVST+ is the recommended mode for all modern Cisco campus and enterprise deployments.
SW-A(config)# spanning-tree mode rapid-pvst
This command switches the entire device from PVST+ to Rapid PVST+. Apply it to all switches in the domain simultaneously, or be prepared for a brief period of mixed-mode operation where some switches run 802.1D compatibility mode.
MST (802.1s Multiple Spanning Tree)
PVST+ and Rapid PVST+ have a scaling problem: if you have 500 VLANs, you have 500 STP instances, each consuming CPU for BPDU processing, topology maintenance, and MAC table management. In practice this is rarely a problem for most deployments, but it can be significant on large campus networks.
MST (802.1s) maps multiple VLANs to a small number of STP instances. A typical MST deployment might use two instances: Instance 1 handles VLANs 1-100, Instance 2 handles VLANs 101-200. The root bridge for each instance can be different, preserving VLAN-based load balancing while dramatically reducing the number of STP instances.
MST is more complex to configure and operate than Rapid PVST+. For most networks, Rapid PVST+ is the better choice. MST is appropriate for very large networks with hundreds of VLANs where PVST+ overhead is measurably impacting switch performance.
| Mode | Standard | Per-VLAN? | Convergence | Use Case |
|---|---|---|---|---|
| STP (PVST+) | 802.1D | Yes | 30-50s | Legacy, avoid |
| Rapid PVST+ | 802.1w | Yes | <1s | Default choice |
| MST | 802.1s | Grouped | <1s | Large-scale only |
PortFast: Edge Port Optimization
What PortFast Does
When an end host connects to a switch access port, the port normally progresses through Blocking, Listening, Learning, and Forwarding — taking up to 30 seconds to pass through the two Forward Delay periods. During this time, the host cannot communicate. DHCP requests time out. Login processes fail. Users complain.
PortFast tells STP that this port is connected to an end device and should skip straight to Forwarding on link-up. The port transitions immediately from Blocking to Forwarding without passing through Listening or Learning. The port still participates in STP — it still sends and receives BPDUs, and it will process superior BPDUs if received — but it does not undergo the timer-based delay.
For RSTP, PortFast configures the port as an Edge Port, which enables the same immediate-forwarding behavior and also triggers immediate TC notifications when the port state changes.
When to Use PortFast
PortFast is appropriate for any port connected exclusively to an end device: workstations, laptops, servers, IP phones, printers, cameras. It is never appropriate for switch-to-switch links. If a PortFast port is connected to another switch, you have not prevented a loop — you have simply reduced the time STP has to detect and prevent it.
The danger is this: a PortFast port transitions to Forwarding immediately. If a loop exists (the switch on the other end connects back to the network through another path), that loop carries live traffic for the milliseconds before STP detects the BPDU and triggers reconvergence. In practice, this brief window combined with broadcast traffic can degrade the network noticeably. BPDU Guard (described below) is the correct mitigation.
PortFast Configuration
! Global: applies PortFast to all access ports (not trunk ports)
SW-A(config)# spanning-tree portfast default
! Per-interface: explicit PortFast on an access port
SW-A(config)# interface GigabitEthernet0/1
SW-A(config-if)# spanning-tree portfast
%Warning: portfast should only be enabled on ports connected to a single
host. Connecting hubs, concentrators, switches, bridges, etc... to this
interface when portfast is enabled, can cause temporary bridging loops.
Use with CAUTION
%Portfast has been configured on GigabitEthernet0/1 but will only
have effect when the interface is in a non-trunking mode.
! For trunk ports connected to servers with virtualization (VMware, Hyper-V)
! Use with care -- only when you know no switch will be connected
SW-A(config-if)# spanning-tree portfast trunk
PortFast Global vs Per-Interface: Operational Detail
spanning-tree portfast default enables PortFast on all access ports (ports in access mode, not trunks). It does not enable PortFast on trunk ports — you must use spanning-tree portfast trunk explicitly for that.
When an interface in Portfast-default mode transitions to trunk mode (for example, due to DTP negotiation with a connected switch), PortFast is automatically disabled on that interface. This provides a safety net, though it is not a substitute for explicit protection.
Verify PortFast status:
SW-A# show spanning-tree interface GigabitEthernet0/1 portfast
VLAN0001 enabled
BPDU Guard: Protecting the Access Layer
The Rogue Switch Problem
PortFast gets ports to Forwarding quickly, but it does nothing to prevent a user from connecting an unmanaged switch to their access port. An unmanaged switch creates a new segment. If it is connected to multiple switch ports (through multiple wall jacks, for example), it creates a loop. Worse, if someone connects a managed switch running STP with a lower Bridge ID than your carefully configured root bridge, that switch could win the root election and take over your topology — redirecting traffic, creating suboptimal paths, and potentially causing a network outage.
BPDU Guard prevents this. A PortFast port should never receive a BPDU — end devices do not send BPDUs. If a BPDU is received on a BPDU Guard-enabled port, BPDU Guard immediately shuts the port down by placing it in err-disable state. The port shows as err-disabled in show interfaces, is removed from all forwarding tables, and stays down until manually re-enabled or automatically recovered via errdisable recovery.
This is not a graceful shutdown — it is an immediate, hard disable. The connected device loses network access instantly. This is intentional: the assumption is that a BPDU on an access port indicates either a security incident or a misconfiguration, both of which warrant immediate investigation rather than graceful degradation.
BPDU Guard Configuration
! Global: enables BPDU Guard on all PortFast-enabled ports
SW-A(config)# spanning-tree portfast bpduguard default
! Per-interface: explicit BPDU Guard (does not require PortFast to be configured)
SW-A(config)# interface GigabitEthernet0/1
SW-A(config-if)# spanning-tree bpduguard enable
! Verify err-disable state
SW-A# show interfaces GigabitEthernet0/1
GigabitEthernet0/1 is down, line protocol is down (err-disabled)
...
SW-A# show errdisable recovery
ErrDisable Reason Timer Status Timer Interval
----------------- -------------- --------------
bpduguard Disabled 300
...
Recovering from err-disable
Two options:
Manual recovery (safer — requires human acknowledgment):
SW-A(config)# interface GigabitEthernet0/1
SW-A(config-if)# shutdown
SW-A(config-if)# no shutdown
! Cycling the port clears err-disable for that interface
Automatic recovery (convenient, but re-enables the port regardless of whether the problem is resolved):
SW-A(config)# errdisable recovery cause bpduguard
SW-A(config)# errdisable recovery interval 300
! Port will automatically re-enable after 300 seconds
! If the rogue device is still connected, it will immediately trigger err-disable again
! You will see this as a repeating err-disable cycle in the logs
! Verify automatic recovery config
SW-A# show errdisable recovery
ErrDisable Reason Timer Status Timer Interval
----------------- -------------- --------------
bpduguard Enabled 300
! Monitor for repeating err-disable (indicates unresolved problem)
SW-A# show log | include err-disabled
%PM-4-ERR_DISABLE: bpduguard error detected on Gi0/1, putting Gi0/1 in err-disable state
%PM-4-ERR_RECOVER: Attempting to recover from bpduguard err-disable state on Gi0/1
%PM-4-ERR_DISABLE: bpduguard error detected on Gi0/1, putting Gi0/1 in err-disable state
A port cycling through err-disable repeatedly at 300-second intervals indicates a live problem. Investigate and physically disconnect the offending device before enabling automatic recovery.
Other STP Protection Features
BPDU Filter
BPDU Filter suppresses BPDU transmission and reception on a port. When enabled globally on PortFast ports (spanning-tree portfast bpdufilter default), it suppresses BPDUs on all PortFast-enabled ports. If the port receives a BPDU, PortFast is disabled and the port operates normally — a safety behavior.
When enabled per-interface (spanning-tree bpdufilter enable), the behavior is more dangerous: it unconditionally suppresses all BPDUs in both directions. The port never processes received BPDUs and does not send them. If this port is part of a loop, STP will never know — and the loop will run forever.
Operational guidance: Use BPDU Filter only with full understanding of the topology. Its primary legitimate use case is on ports connecting to service provider networks where you do not want to exchange STP BPDUs with the provider. BPDU Guard is almost always the better choice for access port protection.
Root Guard
Root Guard prevents a port from ever becoming a root port. If a superior BPDU is received on a Root Guard-enabled port — meaning the connected switch is advertising a lower Bridge ID than the current root — the port is placed in the root-inconsistent state (blocking) rather than transitioning to root port. This protects the placement of your root bridge.
! Apply Root Guard on ports facing switches you do NOT want to become root
SW-DISTRIB(config)# interface GigabitEthernet0/1
SW-DISTRIB(config-if)# spanning-tree guard root
! Verify
SW-A# show spanning-tree inconsistentports
Name Interface Inconsistency
---------------------- ---------------------- ------------------
VLAN0001 GigabitEthernet0/1 Root Inconsistent
The port returns to normal STP operation once it stops receiving superior BPDUs (the rogue switch is disconnected or its priority is raised).
Root Guard is placed on distribution layer ports facing access switches — anywhere a downstream switch might inadvertently or maliciously claim the root bridge role.
Loop Guard
Loop Guard protects against unidirectional link failures — situations where a fiber link carries traffic in one direction but not the other. This can happen with a single-mode fiber break that affects only one strand, or with certain SFP failures.
Without Loop Guard: if a designated port stops receiving BPDUs (because the upstream switch stopped sending them due to a unidirectional failure), STP eventually times out and transitions the port through Listening and Learning to Forwarding. Now two ports on the same segment are in Forwarding state — a loop.
With Loop Guard: when a port that was receiving BPDUs stops receiving them, instead of transitioning toward Forwarding, the port is placed in loop-inconsistent state (effectively blocking). It will return to normal operation when BPDUs resume. Loop Guard is configured on ports where you expect to receive BPDUs — root ports and alternate ports.
SW-A(config)# interface GigabitEthernet0/1
SW-A(config-if)# spanning-tree guard loop
! Or enable globally:
SW-A(config)# spanning-tree loopguard default
Note: Root Guard and Loop Guard are mutually exclusive on the same port. Root Guard detects superior BPDUs and blocks; Loop Guard detects absent BPDUs and blocks. Their use cases are different — Root Guard on ports facing downstream switches, Loop Guard on uplink ports.
UDLD (Unidirectional Link Detection)
UDLD is not a STP feature per se — it is a Cisco-proprietary Layer 2 protocol that detects unidirectional link failures at the physical layer, before STP has a chance to react. UDLD sends periodic frames in both directions; if a switch stops receiving UDLD frames from a neighbor that is still transmitting, it marks the link as unidirectional and disables it.
SW-A(config)# udld enable
! Or per-interface for aggressive mode (faster detection):
SW-A(config)# interface GigabitEthernet0/1
SW-A(config-if)# udld port aggressive
UDLD and Loop Guard are complementary. UDLD detects the failure at the physical layer and shuts the port down before STP can create a loop. Loop Guard is the STP-layer safety net if UDLD misses a failure or is not configured. Run both on inter-switch links in production.
Cisco IOS Commands: Complete Reference
Display Commands
! Per-VLAN summary of all spanning tree instances on the switch
SW-A# show spanning-tree
! Detailed view for a specific VLAN
SW-A# show spanning-tree vlan 10
! Extended detail: timers, topology change history, per-port detail
SW-A# show spanning-tree detail
! Summary of all STP instances: root bridge, mode, BPDU guard status
SW-A# show spanning-tree summary
! Per-interface STP detail for a specific port
SW-A# show spanning-tree interface GigabitEthernet0/1 detail
! Check for ports in loop-inconsistent or root-inconsistent state
SW-A# show spanning-tree inconsistentports
! Check PortFast configuration on a specific interface
SW-A# show spanning-tree interface GigabitEthernet0/1 portfast
! Check errdisable causes and timers
SW-A# show errdisable recovery
! Check interfaces in err-disable state
SW-A# show interfaces status err-disabled
Configuration Commands
! Switch STP mode (apply to all switches)
SW-A(config)# spanning-tree mode rapid-pvst
! Set root bridge for a VLAN (sets priority to beat current root)
SW-A(config)# spanning-tree vlan 10 root primary
! root primary sets priority to 24576 if current root has default priority,
! or to 4096 if current root already has 24576. It is dynamic -- verify with
! show spanning-tree vlan 10 to confirm the actual priority value set.
! Set secondary root bridge
SW-A(config)# spanning-tree vlan 10 root secondary
! Sets priority to 28672
! Set priority explicitly (use this in production for predictability)
SW-A(config)# spanning-tree vlan 10 priority 4096
! Set port cost for a specific VLAN on an interface
SW-A(config-if)# spanning-tree vlan 10 cost 2
! Set port priority (used for tiebreaking, default 128)
SW-A(config-if)# spanning-tree port-priority 64
! Use long-mode path costs (needed for >10G links)
SW-A(config)# spanning-tree pathcost method long
! PortFast global (all access ports)
SW-A(config)# spanning-tree portfast default
! PortFast per interface
SW-A(config-if)# spanning-tree portfast
! BPDU Guard global (all PortFast-enabled ports)
SW-A(config)# spanning-tree portfast bpduguard default
! BPDU Guard per interface
SW-A(config-if)# spanning-tree bpduguard enable
! BPDU Filter global (PortFast ports -- disables if BPDU received)
SW-A(config)# spanning-tree portfast bpdufilter default
! BPDU Filter per interface (unconditional -- use with extreme care)
SW-A(config-if)# spanning-tree bpdufilter enable
! Root Guard on interface
SW-A(config-if)# spanning-tree guard root
! Loop Guard on interface
SW-A(config-if)# spanning-tree guard loop
! Loop Guard globally
SW-A(config)# spanning-tree loopguard default
! errdisable auto-recovery
SW-A(config)# errdisable recovery cause bpduguard
SW-A(config)# errdisable recovery interval 300
! Adjust timers (on root bridge)
SW-A(config)# spanning-tree vlan 1 hello-time 2
SW-A(config)# spanning-tree vlan 1 forward-time 15
SW-A(config)# spanning-tree vlan 1 max-age 20
! Debug STP events (use with caution in production -- can be verbose)
SW-A# debug spanning-tree events
Annotated show spanning-tree vlan 10 Output
The following is complete output from show spanning-tree vlan 10 on a non-root switch running Rapid PVST+, annotated field by field.
SW-B# show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol rstp (1)
Root ID Priority 4106 (2)
Address aabb.cc00.0100 (3)
Cost 4 (4)
Port 1 (GigabitEthernet0/1) (5)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec (6)
Bridge ID Priority 32778 (priority 32768 sys-id-ext 10) (7)
Address aabb.cc00.0200 (8)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec (9)
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/0 Desg FWD 4 128.1 P2p (10)
Gi0/1 Root FWD 4 128.2 P2p (11)
Gi0/2 Altn BLK 4 128.3 P2p (12)
Gi0/3 Desg FWD 4 128.4 P2p Edge (13)
(1) Spanning tree enabled protocol rstp
This switch is running Rapid PVST+, which maps to RSTP (802.1w) per-VLAN. If this showed ieee, the switch would be running classic 802.1D PVST+.
(2) Root ID Priority 4106
The root bridge for VLAN 10 has an effective priority of 4106. This breaks down as: configured priority 4096 + VLAN ID 10 = 4106. Someone explicitly set spanning-tree vlan 10 priority 4096 on the root bridge.
(3) Root ID Address aabb.cc00.0100
The MAC address component of the root bridge’s Bridge ID. This is the base MAC of the root switch. If you need to find which physical switch this is, show version on that switch will show the base MAC.
(4) Cost 4 This switch’s root path cost — the total cost to reach the root bridge. A single 1 Gbps link with default short-mode cost = 4. If this were 8, there would be two 1 Gbps hops to the root.
(5) Port 1 (GigabitEthernet0/1) The local root port — the port on this switch through which the best path to the root exits. Port 1 is Gi0/1. All traffic toward the root bridge leaves through Gi0/1.
(6) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec These are the root bridge’s timer values, carried in the BPDUs from the root. These govern all STP timing decisions for this VLAN across the entire spanning tree. The local switch’s configured timers are irrelevant — the root’s timers are authoritative.
(7) Bridge ID Priority 32778 (priority 32768 sys-id-ext 10) This switch’s own Bridge ID. Effective priority 32778 = configured priority 32768 + VLAN 10. The parenthetical breaks it down explicitly. This switch will lose any root election against a switch with priority below 32768 for VLAN 10.
(8) Bridge ID Address aabb.cc00.0200 This switch’s own MAC address. Combined with priority 32778, this forms the full Bridge ID: 32778/aabb.cc00.0200. The root’s Bridge ID (4106/aabb.cc00.0100) is lower on the priority component, so the root election is not contested.
(9) Aging Time 300 sec Under normal (non-TC) conditions, MAC address entries age out after 300 seconds of inactivity. During a topology change event, this drops to Forward Delay (15 seconds) to flush stale entries. If this shows 15 during normal operation, a topology change is currently in progress — investigate.
(10) Gi0/0 Desg FWD 4 128.1 P2p Gi0/0 is a Designated port in Forwarding state. Cost 4 (1 Gbps link). Port ID 128.1 means priority 128 (default) and port number 1. P2p means this is a point-to-point link (full-duplex), which is required for RSTP’s Proposal/Agreement mechanism to work. On a half-duplex or hub-connected port, RSTP falls back to 802.1D behavior.
(11) Gi0/1 Root FWD 4 128.2 P2p This is the root port — the best path to the root bridge. In Forwarding state, cost 4. This is the port identified in field (5) above.
(12) Gi0/2 Altn BLK 4 128.3 P2p An RSTP Alternate port in the Discarding (Blocking) state. This port provides a path to the root but is not the best path. If Gi0/1 fails, Gi0/2 can transition to Forwarding rapidly because it already knows its root path cost (4+4=8 via another switch). The “Altn” role is the RSTP equivalent of classic STP’s non-designated/blocking port, but with the fast-failover capability.
(13) Gi0/3 Desg FWD 4 128.4 P2p Edge A Designated port in Forwarding state with the Edge designation — this is a PortFast port. The “Edge” flag confirms that PortFast is configured and active. Edge ports do not participate in the Proposal/Agreement handshake and transition immediately to Forwarding on link-up.
Full Lab Configuration: 3-Switch Topology
This is a complete, tested configuration for a three-switch lab topology with correct root bridge placement, Rapid PVST+, PortFast on all access ports, and BPDU Guard throughout. The topology uses SW-CORE as the access/distribution root for VLANs 10 and 20, with SW-ACC-A and SW-ACC-B as access layer switches.
Topology:
+------------+
| SW-CORE |
| Gi0/0-1 |
+----+--+----+
| |
Gi0/1 trunk| |Gi0/1 trunk
| |
+----------+ +-----------+
| |
Gi0/1 trunk Gi0/1 trunk
+----------+ +----------+
| SW-ACC-A | | SW-ACC-B |
| Gi0/2-3 | | Gi0/2-3 |
| access | | access |
+----------+ +----------+
| | | |
host1 host2 host3 host4
(Gi0/2)(Gi0/3) (Gi0/2)(Gi0/3)
SW-CORE Configuration
! --- SW-CORE ---
hostname SW-CORE
! VLANs
vlan 10
name USERS
vlan 20
name SERVERS
! Use Rapid PVST+ on all switches
spanning-tree mode rapid-pvst
! Make SW-CORE root bridge for both VLANs with explicit priority
! Priority 4096 gives headroom -- any accidental switch with default 32768 will lose
spanning-tree vlan 10 priority 4096
spanning-tree vlan 20 priority 4096
! Use long-mode path costs if any links are >= 10G
! spanning-tree pathcost method long
! Trunk uplinks to access switches
interface GigabitEthernet0/0
description Trunk-to-SW-ACC-A
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,20
! Root Guard: prevent access switches from claiming root
spanning-tree guard root
no shutdown
interface GigabitEthernet0/1
description Trunk-to-SW-ACC-B
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,20
spanning-tree guard root
no shutdown
SW-ACC-A Configuration
! --- SW-ACC-A ---
hostname SW-ACC-A
! VLANs
vlan 10
name USERS
vlan 20
name SERVERS
spanning-tree mode rapid-pvst
! Access switches should NOT be root -- set priority higher than SW-CORE
! Default 32768 is fine, but being explicit is better practice
spanning-tree vlan 10 priority 32768
spanning-tree vlan 20 priority 32768
! Enable PortFast globally on all access ports
spanning-tree portfast default
! Enable BPDU Guard globally on all PortFast-enabled ports
spanning-tree portfast bpduguard default
! Configure errdisable auto-recovery for bpduguard
! (optional -- manual recovery is safer; auto-recovery here for lab convenience)
errdisable recovery cause bpduguard
errdisable recovery interval 300
! Uplink trunk to SW-CORE
interface GigabitEthernet0/1
description Trunk-to-SW-CORE
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,20
! Loop Guard on uplink: protect against unidirectional fiber failures
spanning-tree guard loop
! PortFast must NOT be active on trunk/uplink ports
! (portfast default does not apply to trunks, so we are safe)
no shutdown
! Access ports -- VLAN 10 (Users)
interface GigabitEthernet0/2
description Access-Host1-VLAN10
switchport mode access
switchport access vlan 10
! PortFast and BPDU Guard are applied via global defaults above
! You can verify with: show spanning-tree interface Gi0/2 portfast
no shutdown
interface GigabitEthernet0/3
description Access-Host2-VLAN10
switchport mode access
switchport access vlan 10
no shutdown
SW-ACC-B Configuration
! --- SW-ACC-B ---
hostname SW-ACC-B
vlan 10
name USERS
vlan 20
name SERVERS
spanning-tree mode rapid-pvst
spanning-tree vlan 10 priority 32768
spanning-tree vlan 20 priority 32768
spanning-tree portfast default
spanning-tree portfast bpduguard default
errdisable recovery cause bpduguard
errdisable recovery interval 300
interface GigabitEthernet0/1
description Trunk-to-SW-CORE
switchport trunk encapsulation dot1q
switchport mode trunk
switchport trunk allowed vlan 10,20
spanning-tree guard loop
no shutdown
interface GigabitEthernet0/2
description Access-Host3-VLAN20
switchport mode access
switchport access vlan 20
no shutdown
interface GigabitEthernet0/3
description Access-Host4-VLAN20
switchport mode access
switchport access vlan 20
no shutdown
Verification Commands for the Lab
! Confirm SW-CORE is root for both VLANs
SW-CORE# show spanning-tree summary
Switch is in rapid-pvst mode
Root bridge for: VLAN0010 VLAN0020
...
! Confirm access switches show SW-CORE as root
SW-ACC-A# show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 4106
Address <SW-CORE MAC>
Cost 4
Port 1 (GigabitEthernet0/1)
...
! Verify PortFast is active on access ports
SW-ACC-A# show spanning-tree interface GigabitEthernet0/2 portfast
VLAN0010 enabled
! Verify BPDU Guard is active
SW-ACC-A# show spanning-tree summary
...
PortFast BPDU Guard Default is enabled
! Test BPDU Guard by connecting a switch to an access port
! The port should go err-disabled immediately
SW-ACC-A# show interfaces status err-disabled
Port Name Status Reason
Gi0/2 Access-Host1-VLAN10 err-disabled bpduguard
! Check topology change counters
SW-CORE# show spanning-tree detail | include topology
Number of topology changes 2 last change occurred 00:15:30 ago
! Confirm no root inconsistent ports
SW-CORE# show spanning-tree inconsistentports
Name Interface Inconsistency
---------------------- ---------------------- ------------------
No inconsistent ports
Troubleshooting STP: Common Problems and Diagnosis
Wrong Root Bridge Elected
Symptom: traffic takes unexpected paths, high latency, one switch handling disproportionate traffic load.
Diagnosis:
SW-A# show spanning-tree vlan 1
! Check Root ID section -- is the root the switch you intended?
! If not, find which switch has the lower Bridge ID
SW-A# show spanning-tree vlan 1 | include Root
Root ID Priority 32769
Address aabb.cc00.0101
The most common cause: a new switch was added with default priority (32768) and happened to have a lower MAC address than the current root. Or an access layer switch was connected before the distribution switch was configured as root.
Resolution:
! On the intended root switch:
SW-CORE(config)# spanning-tree vlan 1 priority 4096
! On all distribution and access switches -- verify they are NOT root:
SW-ACC-A(config)# spanning-tree vlan 1 priority 32768
Prevention: configure Root Guard on all distribution-to-access downlinks so that access switches can never win a root election.
Port Stuck in Blocking (Should Be Forwarding)
Symptom: hosts on a specific switch cannot reach the network. The switch has connectivity but a port refuses to go Forwarding.
Diagnosis:
SW-B# show spanning-tree vlan 1
Interface Role Sts Cost Prio.Nbr Type
Gi0/2 Altn BLK 4 128.3 P2p
! Gi0/2 is in Alternate/Blocking
! Is this intentional? Check whether this port should be a designated port.
! Check what BPDU this port is receiving:
SW-B# show spanning-tree vlan 1 detail
...GigabitEthernet0/2 of VLAN0001 is alternate blocking
Port info port id 128.3 priority 128 cost 4
Designated root has priority 4097, address aabb.cc00.0100
Designated bridge has priority 32769, address aabb.cc00.0200
Designated port id 128.2, cost 4
...
! The designated bridge address (aabb.cc00.0200) is another switch
! That switch won the designated port election for this segment
! This is correct STP behavior -- not a fault
If a port is Blocking and you believe it should be Forwarding:
- Verify you understand the topology correctly — draw it out
- Trace the root path cost from each switch on the contested segment to the root
- Compare Bridge IDs as tiebreaker
- If the wrong switch won, adjust priorities
If a port should be a designated port but it is receiving superior BPDUs it should not:
! Check if root guard is triggering
SW-A# show spanning-tree inconsistentports
STP Loop Symptoms
A Layer 2 loop that STP failed to prevent (due to STP being disabled, a misconfiguration, or a rare race condition) produces a distinctive signature:
- CPU spikes to 100% on affected switches. The switch interrupt handler is processing millions of frames per second.
- Broadcast or multicast traffic floods all ports continuously. Network analyzers show impossibly high frame rates.
- MAC table instability:
show mac address-tableshows MAC addresses moving between ports at high frequency. The syslog fills with%SW_MATM-4-MACFLAP_NOTIFmessages. - Management access fails: SSH sessions time out, SNMP polls fail. The switch CPU is too busy to respond.
- No topology change convergence: The storm continues indefinitely until the loop is physically broken.
Resolution procedure:
- Identify the switches involved from the MAC flapping logs
- Physically disconnect the redundant link creating the loop
- Verify the storm has stopped (CPU returns to normal)
- Identify why STP failed to block the loop:
- Was STP disabled on one or more switches?
- Was PortFast enabled on an inter-switch link?
- Did a BPDU Filter suppress the BPDU that would have triggered blocking?
- Fix the root cause before reconnecting the link
! Find MAC flapping during a loop
SW-A# show log | include MACFLAP
%SW_MATM-4-MACFLAP_NOTIF: Host aabb.cc11.0001 in vlan 1 is flapping
between port Gi0/1 and port Gi0/2
! Find which VLANs are experiencing topology changes
SW-A# show spanning-tree detail | include topology
Number of topology changes 4421 last change occurred 00:00:02 ago
! Very high topology change counts with recent timestamps indicate a loop
! or a severely flapping link
Topology Change Storms
Excessive topology changes degrade the network even without a full loop. Each TC event causes a MAC table flush on every switch, followed by a wave of flooding as MAC addresses are relearned.
Common causes:
- An access port without PortFast (a PC port that goes up and down generates TCs)
- A flapping uplink
- A misconfigured server with a bonded NIC that triggers TC events when switching between bonded members
! Identify which port is generating TCs
SW-A# show spanning-tree detail | include GigabitEthernet
! Look for "from GigabitEthernet X/Y" near topology change messages
! Targeted fix: enable PortFast on the offending access port
SW-A(config)# interface GigabitEthernet0/5
SW-A(config-if)# spanning-tree portfast
Key Exam Points Summary
The following table consolidates the most exam-tested facts for CCNA:
| Topic | Key Value / Fact |
|---|---|
| Default bridge priority | 32768 |
| Priority increment | 4096 |
| Valid priorities | 0, 4096, 8192, …, 61440 |
| Bridge ID size | 8 bytes (2 priority + 6 MAC) |
| Root election criterion | Lowest Bridge ID |
| Root path cost (1 Gbps, short) | 4 |
| Root path cost (100 Mbps, short) | 19 |
| Root path cost (10 Mbps, short) | 100 |
| Tiebreaker order | Cost → Sender BID → Sender Port ID → Local Port ID |
| Blocking state duration (max) | 20s (Max Age) |
| Listening state duration | 15s (Forward Delay) |
| Learning state duration | 15s (Forward Delay) |
| Total 802.1D convergence (worst) | 50s |
| Hello Time default | 2s |
| Max Age default | 20s |
| Forward Delay default | 15s |
| RSTP port states | Discarding, Learning, Forwarding |
| RSTP new roles vs 802.1D | Alternate Port, Backup Port, Edge Port |
| Cisco default STP mode | PVST+ (classic) on older IOS; verify with show spanning-tree summary |
| PortFast purpose | Skip Listening/Learning on access ports |
| BPDU Guard action | err-disable port on BPDU receipt |
| Root Guard action | root-inconsistent (blocking) on superior BPDU |
| Loop Guard action | loop-inconsistent (blocking) on BPDU absence |
Closing Notes
STP is often treated as background infrastructure — something you configure once and forget. That approach works until it doesn’t. A misconfigured priority, a rogue switch, or a PortFast trunk port that slips through review can create an outage that takes hours to diagnose because the symptoms (broadcast storm, MAC flapping, unreachable devices) look superficially like many other problems.
Three habits that prevent most STP-related outages in production:
First, always configure root bridge priorities explicitly. Do not rely on the default 32768 and hope the right switch happens to have the lowest MAC. Set priority 4096 on your intended roots and document it. Add Root Guard on all downlink ports from distribution to access so that the topology is self-healing if someone adds an unconfigured switch.
Second, run Rapid PVST+ everywhere. Classic 802.1D has no place in a modern network. The 50-second convergence timer is not acceptable for any production application. The configuration change is a single line (spanning-tree mode rapid-pvst) and the operational complexity is the same.
Third, apply PortFast and BPDU Guard together on every access port. PortFast without BPDU Guard is a loaded gun with no safety. BPDU Guard without PortFast is redundant noise. They belong together on every host-facing port, configured globally so that new ports get the correct behavior automatically without relying on individual engineers to remember per-port configuration.
STP is deterministic once you internalize the election algorithm. Given any topology diagram and a set of Bridge IDs and port costs, you can trace exactly which ports will block and which will forward. That analytical skill — not memorizing Cisco commands — is what the CCNA is testing, and it is what makes the difference between an engineer who can configure STP and one who can troubleshoot it.
Comments