Why Spanning Tree Protocol is Used
This short section describes why the Spanning-Tree Protocol is used.
It’s easy to connect a bunch of computers to a switch, and connect the switch to its gateway, and you get a full simple network. But then you add another switch and run dual cables between the old switch and the new one. You think you’re adding redundancy, right?
It’s true that, in a switched network, we add links between switches for redundancy, so when a switch link fails, there is still another one that can bear network traffic.
But adding redundant physical links between switches creates potential switching loops. This is true especially when switches are in flooding mode, such as in Multicast transmission.
That’s where Spanning Tree Protocol comes in.
Spanning Tree Protocol creates a loop-free switching path between all switches in an Ethernet network. The way it does it is by “deactivating” certain ports on the path. So if we take the previous network diagram, the new network topology becomes something like this:
The spanning tree is rooted in one switch called the Root Bridge. It means that one switch will be the source from which branches originate.
One Root Bridge -aka Root Switch- is elected. All the remaining switches are called Non-Root Bridges.
STP BID and Root Bridge
Each BPDU contains the Bridge ID (or BID for short). The Bridge ID is composed of:
- the bridge priority
- the bridge MAC address
The default bridge priority value is 32768. When there ‘s a tie in the priority, the bridge with the lowest MAC address wins the elections and becomes the Root Bridge.
Once the Root Bridge is elected, all BPDUs are emitted only from the Root Bridge; the non-Root Bridges simply forward copies of the Root Bridge’s BPDUs.
The BPDU sent by the Root Bridge is called Superior BPDU
Port States
A spanning tree port is in one of the following states:
- Disabled: Spanning tree protocol is disabled
- Listening
- Learning
- Forwarding
- Blocking
When the port in the Listening or Blocking state, the switch can not learn new MAC addresses from Ethernet frames received on this port.
Electing a Root Bridge for a VLAN
This is the topology I’m using for this example:
S2 and S4 are two Cisco Catalyst switches. Both have the same Bridge priority, which was the default 32768 + the Vlan ID number. So the tie is the MAC address.
Now I want to apply “root secondary” without applying “root primary”. Here’s the bridge priority on the target switch:
and now I apply “spanning-tree vlan 2 root secondary” on S4:
Despite that, S4 became the root bridge for vlan 2!
Setting bridge priorities
When the extended VLAN feature is used
If the Extended System ID feature is enabled on a switch, we can set bridge priorities only in increments of 4096:
Setting bridge priority manually
If the Extended System ID feature is enabled, and we set the bridge priority manually, then the real priority that the switch registers is:
the priority value we’ve entered plus the VLAN ID number:
BID vs RID
The Root ID is the Bridge ID of the root bridge. The Bridge ID is the ID of the switch that generated the BPDU. If, in a BPDU the Root ID is equal to the Bridge ID, then the current switch is the root of the spanning tree. Otherwise, the root bridge is another switch.
Spanning Tree Root Path Cost and Path Cost
The Spanning tree Root Path Cost RPC is the cost from the root of the spanning tree to the current switch. Its value is 0 at the root bridge. It increases as Ethernet BPDU frames go down the path to the non-root bridges.
When a non-root bridge receives the superior BPDU over its Root Port, it increases the Root Path Cost by the Path Cost (aka Port Cost) value.
The table below summarizes the standard Port Cost values:
Port path cost and root path cost
– Port Path Cost = STP cost of the interface = port cost
– Root Path Cost = cumulative STP costs of interfaces along the way = Sum(port costs).
Spanning Tree Root Port Election: How does it work?
We said that non-root ridges have one Root Port. But how is it chosen?
The Root Port is elected by the following criteria:
- the port that receives the superior BPDU
- the port with the lowest Root Path Cost
- the port that received the BPDU containing the lowest sender’s Bridge ID
- the port that receives the BPDU with the lowest sender’s port ID
To understand this, here is a simple two-switch setup:
Both switches announce themselves as a root bridge. Then switch B receives a superior BPDU on both its interfaces.
- both ports on switch B receive a same superior BPDU –> tie
since both ports received the same superior BPDU, there is a same Root Path Cost –> tie
Both interfaces connect directly to the root bridge. So they receive BPDU frames with a same Bridge ID –> tie
The last chance is to verify which is interface receives a BPDU with the lowest sender’s port ID. Fa0/1 receives a BPDU with Port ID of 32769. Fa0/2 receives a BPDU with Port ID of 32770.
The Port ID in the BPDU received by Fa0/1 is the lowest, so Fa0/1 becomes the Root Port (in the Forwarding state) and Fa0/2 is put in the Blocking state. Notice the amber color:
Spanning Tree Q&A
Why do we use the term “bridge” and not “switch”?
Spanning tree has been there a long time ago, even before the appearance of switches. And the terms have not evolved since then. Some people may use the “switch” term in the Spanning Tree jargon. However, most network engineers still use the old “bridge” term.
What’s the difference between a BPDU frame and a BPDU message?
None. It’s really an Ethernet frame with BPDU information in it. We simply call it a BPDU frame or a BPDU message for simplicity.
What is the purpose of a Designated Port between non-root bridges?
A Designated Port (DP) can be found on root bridges and on non-root bridges.
On root bridges, Designated Ports forwards all frames. On non-root bridges, Designated Ports allow frames to egress the interface towards the next switch, whose port will block and discard the frame, since it’s in the Blocking state.
Spanning Tree BPDU Format
Let’s explore the Spanning Tree Protocol BPDU format.
Bridges exchange BPDUs encapsulated into Ethernet frames. There are two types of BPDUs:
- Configuration BPDU
- TCN BPDU
Spanning Tree BPDU: what does it look like in an Ethernet Frame?
Let’s see how a BPDU fits into an Ethernet frame. We should know that STP needs the LLC sub-layer because LLC acts as a transport protocol for STP. So in a STP frame, you’ll find LLC.
If you recall from the Ethernet post, the IEEE 802.3 Ethernet frame with LLC sub-layer is composed of:
- IEEE 802.2 LLC
- IEEE 802.3 MAC
In the Data field of the Ethernet frame lays the BPDU. The BPDU format is as follows:
So When STP process kicks in, it gives its BPDU to the Ethernet protocol which encapsulates the BPDU into an Ethernet frame, in the Data field.
Spanning Tree Operation
how the protocol works
Here is a topology we’re going to work with:
The Root bridge elections start. Switches exchange Ethernet BPDU frames. The BPDUs are Configuration BPDUs.
Every switch in the network starts by claiming that he is the root bridge. Here, let’s examine Switch2.
Switch2 STP process crafts a BPDU where RID=BID.
Let’s examine Switch2 MAC address:
So in the BPDU, RID will be equal to BID:
The Ethernet BPDU frame is sent to the multicast spanning tree address which is 01:80:C2:00:00:00. We can see that by inspecting the destination MAC address of the Ethernet frame:
However, you may notice that the source MAC address of the Ethernet frame (00D0.BC2E.BE02) is different from the MAC address in the Bridge ID (0001.6493.0687). That’s because the former is the MAC address of the interface that sent the frame, while the latter is the MAC address of the switch itself:
Switch0 and Switch1 ports receive the Ethernet frame sent by Switch2. Since the destination address of Switch2’s Ethernet frame is a multicast, then both Switch0 and Switch1 consider the frame. The Ethernet layer decapsulates the PDU: it’s a BPDU. So STP takes charges.
The STP process inspects the BPDU. In our example, Switch2 has the lowest MAC address. Besides, I did not change any priority on any switch. So the STP process on Switch0 and Switch1 finds that it is a superior BPDU:
- Switch0 received the superior BPDU on port f0/2. This will be the root port
- Switch1 received the superior BPDU on port f0/2. This will be the root port
After Switch1 receives the Ethernet BPDU frame and discovers it is a superior BPDU, it crafts an Ethernet BPDU frame and sends it. We clearly see that the bridge ID is different from the Root bridge ID.
Switch0 is tuned to the spanning tree multicast address and hears an Ethernet frame on it. It decapsulates the PDU and finds out it’s a BPDU. The Spanning tree process takes charge and inspects the BPDU. There’s nothing new, because Switch0 already had received this information -which is a superior BPDU- from Switch2.
Spanning tree has converged and the tree is as follows:
Spanning Tree Protocol in Wireshark
Let’s look at a topology that involves three looped switches. In GNS3, I am using vIOS-L2 devices, which are virtual layer 2 IOS images. All switches have the default bridge priority. So it’s the bridge MAC address that will break the tie.
We’ll start all switches and see what happens in the Spanning Tree Root Bridge election. Here is the topology:
Here are the MAC addresses of the switches:
- vIOS-L2-1 (switch 1): 0000.ab6f.1700
- vIOS-L2-2 (switch 2): 0000.ab64.1700
- vIOS-L2-3 (switch 3): 0000.abbd.ce00
According to the spanning tree algorithm, each one of the switches is considered a potential root bridge. We should have at the end the switch vIOS-L2-2 as the root bridge, since it has the lowest MAC address.
In Wireshark, RID is referred to as Root Identifier and BID is referred to as Bridge Identifier.
At bootup, only Switch 1 STP frames are seen on the wire. All switches set Switch 1 as their spanning tree Root Bridge.
Switch 2 and Switch 3 receive the Ethernet BPDU frame where Switch 1 is the Root Bridge:
Switch 2 too advertises its STP frames. Its Ethernet BPDU frame reaches the other switches. They realize that Switch 2 has sent a superior BPDU. Thus, Switch 2 becomes the root bridge:
Sometimes you get a Wireshark trace where the root bridge “seems” to flap:
In reality, there is a tiny field that makes the difference: the VLAN ID field. Spanning Tree runs for each VLAN and a separate Root Bridge election occurs on each VLAN. So one switch can be the Root Bridge for VLAN 1 and another switch will be the Root Bridge for VLAN 100.
STP vs RSTP: Topology Change
Topology Change Event Trigger
Topology Change Detection Time
Spanning Tree BPDU Filter
There are two seperate ways to configure it:
- globally.
- per portfast interface.
Configure STP BPDU filter globally
(config)#spanning-tree portfast bpdufilter default
Effects:
- enables BPDU filter on all portfast interfaces
- kicks them out of portfast if they receive a BPDU
Configure STP BPDU per portfast interface
(config-if)#spanning-tree bpdufilter enable
Effects: effectively disables STP on the port. This may lead to switching loops since switches won’t detect redundant links between them.
Loop Guard: global and interface configuration
Enabling Loop Guard on an interface level does not enable it for the whole system. In fact, a “show spanning-tree summary total” is a bit misleading in this case.
to configure loop guard on an interface:
“loop guard default” is disabled because we haven’t issued a “spanning-tree loopguard default”. Easy:
RSTP and full duplex issue on IOL
Trying to configure duplex settings under an IOL switch interface can be a pain in the ass, especially when you are practicing RSTP and you need to have point-to-point links. You do “show spanning-tree” and you see that your interfaces are still “shared”, which don’t run RSTP:
VLAN0001 Spanning tree enabled protocol rstp Root ID Priority 24577 Address aabb.cc00.1000 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 24577 (priority 24576 sys-id-ext 1) Address aabb.cc00.1000 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Et0/0 Desg FWD 100 128.1 Shr Et0/1 Desg FWD 100 128.2 Shr Et0/3 Desg FWD 100 128.4 Shr
The problem you could encounter is one of these two scenarios:
- despite you are sure you did “duplex full” command under the interface level, you have “auto” when you do “show interface status”
- when you type “duplex full” command, you get the following error: “Autoneg enabled. Duplex cannot be set.”
If you only have IOL images
A useful method to convert switch interface to full duplex modes and enjoy playing with RSTP is to:
- use one of the Advanced Enterprise versions of IOL
- under the desired switch interface
- configure “duplex full”
- configure “spanning-tree link-type point-to-point”
Switch-1#conf t Enter configuration commands, one per line. End with CNTL/Z. Switch-1(config)# *Sep 1 21:56:37.819: %SYS-5-CONFIG_I: Configured from console by console Switch-1(config)#int range e0/0 - 1 , e0/3 Switch-1(config-if-range)#spanning-tree link-type point-to-point
Now RSTP sees the interfaces as point-to-point and should be able to run on them:
Switch-1#sh spanning-tree VLAN0001 Spanning tree enabled protocol rstp Root ID Priority 24577 Address aabb.cc00.1000 This bridge is the root Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 24577 (priority 24576 sys-id-ext 1) Address aabb.cc00.1000 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Et0/0 Desg FWD 100 128.1 P2p Et0/1 Desg FWD 100 128.2 P2p Et0/3 Desg FWD 100 128.4 P2p
However, you’ll notice that:
* although you configured RSTP as the spanning-tree mode,
* although spanning tree seems to detect your switch interfaces as P2P,
The actual convergence times are those of a 802.1d STP.
So a better solution would be the second option, which is:
Alternative to IOL
I wanted to see if vIOS had the same limitations as the IOL in terms of RSTP, and I found:
- the duplex issue is not present with vIOS
Switch#sh int status Port Name Status Vlan Duplex Speed Type Gi0/0 connected 1 a-full auto RJ45 Gi0/1 connected 1 a-full auto RJ45 Gi0/2 connected 1 a-full auto RJ45 Gi0/3 connected 1 a-full auto RJ45
-
- RSTP convergence times are real, and not of a regular 802.1d STP.
Switch#sh spanning-tree
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 32769
Address 5000.0008.0000
Cost 4
Port 1 (GigabitEthernet0/0)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32769 (priority 32768 sys-id-ext 1)
Address 5000.0009.0000
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi0/0 Root FWD 4 128.1 P2p
Gi0/1 Altn BLK 4 128.2 P2p
Gi0/2 Desg FWD 4 128.3 P2p
Gi0/3 Desg FWD 4 128.4 P2p
Switch# Switch#debug spanning-tree switch state Spanning Tree Port state changes debugging is on Switch# Switch#conf t Enter configuration commands, one per line. End with CNTL/Z. Switch(config)#int gi0/0 Switch(config-if)#shut Switch(config-if)# *Sep 1 22:40:34.328: STP SW: Gi0/2 new blocking req for 1 vlans *Sep 1 22:40:34.328: STP SW: Gi0/3 new blocking req for 1 vlans *Sep 1 22:40:34.329: STP SW: Gi0/1 new forwarding req for 1 vlans *Sep 1 22:40:36.322: %LINK-5-CHANGED: Interface GigabitEthernet0/0, changed state to administratively down *Sep 1 22:40:37.322: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to down *Sep 1 22:40:49.329: STP SW: Gi0/2 new learning req for 1 vlans *Sep 1 22:40:49.330: STP SW: Gi0/3 new learning req for 1 vlans *Sep 1 22:41:04.330: STP SW: Gi0/2 new forwarding req for 1 vlans *Sep 1 22:41:04.331: STP SW: Gi0/3 new forwarding req for 1 vlans Switch(config-if)# Switch(config-if)#do sh spanning VLAN0001 Spanning tree enabled protocol rstp Root ID Priority 32769 Address 5000.0008.0000 Cost 4 Port 2 (GigabitEthernet0/1) Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Bridge ID Priority 32769 (priority 32768 sys-id-ext 1) Address 5000.0009.0000 Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec Aging Time 300 sec Interface Role Sts Cost Prio.Nbr Type ------------------- ---- --- --------- -------- -------------------------------- Gi0/1 Root FWD 4 128.2 P2p Gi0/2 Desg FWD 4 128.3 P2p Gi0/3 Desg FWD 4 128.4 P2p Switch(config-if)#no shut Switch(config-if)# *Sep 1 22:41:55.172: STP SW: Gi0/0 new blocking req for 1 vlans *Sep 1 22:41:55.181: STP SW: Gi0/1 new blocking req for 1 vlans *Sep 1 22:41:55.182: STP SW: Gi0/2 new blocking req for 1 vlans *Sep 1 22:41:55.182: STP SW: Gi0/3 new blocking req for 1 vlans *Sep 1 22:41:55.183: STP SW: Gi0/0 new forwarding req for 1 vlans *Sep 1 22:41:57.095: %LINK-3-UPDOWN: Interface GigabitEthernet0/0, changed state to up *Sep 1 22:41:58.094: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/0, changed state to up *Sep 1 22:42:10.184: STP SW: Gi0/2 new learning req for 1 vlans *Sep 1 22:42:10.185: STP SW: Gi0/3 new learning req for 1 vlans *Sep 1 22:42:25.185: STP SW: Gi0/2 new forwarding req for 1 vlans *Sep 1 22:42:25.186: STP SW: Gi0/3 new forwarding req for 1 vlans
MSTP configuration
I configured VLANs, assigned ports to them, configured VTP domain to be the same on both switches, configured trunks, configured MST region with its name, revision number and vlan-to-instance mapping… but I couldn’t see changes when I issue spanning-tree mst {instance} root primary :
then I found the problem: I didn’t choose MST as the spanning-tree mode!
After that, previous “root primary” configuration takes effect.
to check results: show spanning-tree mst configuration, show spanning-tree mst {instance}
Whenever you need a refresher on your CCNA skills and at the same time review at your own pace, then I recommend you to check the new CCNA exam study material.