2-R&S/Spanning Tree Protocol (STP) Part 2.

Let’s continue the STP explanation at the previous post 1-R&S/Virtual LAN (VLAN) and Spanning Tree Protocol (STP), in this post i will mention the different modes and protocols of STP as well some configurations related to STP. At the previous post i stopped at the criteria used by the STP to elect the Root bridge and cut/block one or more of the links forming the ring topology at this Layer 2 switched network that should be blocked to avoid such loop, but i didn’t give an example about how the sending Port ID carried inside the configuration BPDU is used to determine which link should be blocked, so let’s assume the following simple topology:

9We can see here that the Bridge ID of Switch1 is lower than of Switch2 (from numerical value point of view), hence Switch1 is elected as the Root bridge and we have here two links between the two switches which means that there is ring topology and this can cause loop, so the STP should block one of the two links, so let’s follow the STP criteria at the previous post to know which link should be blocked:

1-Switch1 send its configuration BPDU out the two ports (Eth0/1 and Eth1/0) to Switch2.
The following figure shows the two configuration BPDU send by Switch1 out the two ports:

BPDU sent out Ethernet0/1 as seen on Wireshark:

1-2 last

BPDU sent out Ethernet1/0 as seen on Wireshark:

1-2 other

2-Switch2 receives the two configuration BPDUs and start to compare them to know which BPDU is considered to be the superior BPDU, so it follow the criteria.
3-Switch2 check the first field “Root Bridge ID” of the two BPDUs and found that both of them having the same ID, so it check the second step.
4-Switch2 check the second field “Root Path Cost” of the two BPDUs and found that both of them having the same Cost to reach the Root bridge (has value of 0 as Switch1 itself is the Root Bridge), so it check the third step.
5-Switch2 check the third field “Sender Bridge ID” of the two BPDUs and found that both of them having the same ID (as Switch1 is the sender of the two BPDUs and it has single Bridge ID), so it check the fourth step.
6-Switch2 check the fourth field “Sender Port ID” of the two BPDUs and found that the Sender Port ID of the BPDU sent over Eth0/1 has Hex Value of (0x8002) which consists of two fields in Hex (0x80) + (0x02), and if we convert it into decimal, this results in (128) + (2), this means that the first Sender Port ID = 128.2, while the Sender Port ID of the second BPDU sent over Eth1/0 has Hex Value of (0x8005) and if we convert if into decimal, this results in (128.5), this means that Switch2 choose the sender port ID with the lowest numerical value, hence it choose (128.2) which is seen on the port Eth0/1 of Switch2, this results in Switch2 should block the other port Eth1/0, so this results in the following loop-free layer 2 switched network:

9

In the previous part and post i talked about the STP/CST which means that the switch run only one STP instance for all the VLANs, this means that if we have 100 VLANs, the switch creates only one STP instance with one Bridge ID, Topology and its database and data structure, let’s mention the topology of the previous post for more explanation:

11

We can see that there are three different VLANs (PCs, Desktops and Servers) and based on the current design, we run STP/CST, this means that all the VLANs share the same loop-free layer 2 switched network as it run only one STP instance for all VLANs, the below figure shows the result loop-free layer 2 switched network:

11 - Copy

We can see here when Server1 need to communicate with Server2 inside Server VLAN, the traffic take the following path:
(Server1) ——> (Switch3) ——> (Switch1) ——> (Switch2) ——>(Server2)
when Desktop1 need to communicate with Desktop2 inside Desktop VLAN, the traffic take the following path:
(Desktop1) ——> (Switch4) ——> (Switch1) ——> (Switch2) ——>(Desktop2)
And when PC1 need to communicate with PC2 inside PC VLAN, the traffic take the following path:
(PC1) ——> (Switch1) ——> (Switch2) ——>(PC2)

Because of running single STP instance, we can see that inter-switch links (Sw3-Sw4) and (Sw2-Sw4) are totally unused, in case the link (Sw1-Sw4) failed for any possible reason, only one of the links become active and carry the traffic of all the VLANs and the other one still blocked and unused until all the other two links failed, so if those links are 100Mbps or 1Gbps, this means that there are 200Mbps or 2Gbps BW are not utilized during convergence (i.e when the network is stable), so this for sure is not good behavior and needed to be changed to make all the links usable.

Because of the previous issue, let’s talk about the different modes of STP (IEEE 802.1d), so that we can understand what is the difference between running STP/CST or its modes. STP has two different modes, Per VLAN Spanning Tree (PVST) and Per VLAN Spanning Tree Plus (PVST+), as the names imply, it means that when the switch run PVST or PVST+ it run STP process or instance per VLAN, this means that if there are 10 VLANs configured on the VLAN database on the switch, it creates 10 STP instances (one STP instance per VLAN) and each one has its own Bridge ID, topology, database and data structures, but what about 100 VLANs ? yes, it the same, i mean each STP instance has its own topology, database and data structures, what about the Bridge ID ?? here is the issue, some Cisco switches don’t reserve large number of unique MAC addresses, specially don’t reserve more than 64 MAC addresses, and to make each STP instance has its own Bridge ID, this means that some of the switches support only up to 64 MAC addresses, hence this switch can’t create 100 unique Bridge ID, so how can we solve this issue ? IEEE 802.1t is the answer, so what is the 802.1t ? actually it is used to make extension for the ID, what is the meaning of extension for the ID ? as i said the mentioned switch doesn’t reserve more than 64 MAC addresses, hence we need to create 100 Bridge IDs and must be unique as well, so how can this happen ? you know that the Bridge ID consists of two parts (Bridge Priority + MAC address), we already said that this old switch can’t support 100 unique MAC addresses, so we can change in the first part (Bridge Priority) and exactly this is the purpose of the IEEE 802.1t which is used to change the Bridge priority per VLAN, this means that it need to make the Bridge Priority to be unique per VLAN, and it make this by adding the VLAN ID value to the Bridge Priority (automatically without doing it for the 100 VLANs yourself), this means that if Bridge Priority is 32768 (default value) it add the VLAN ID to this value, let’s take an example so that you can understand this point:

Assume that the switch has Base MAC address (aabb.cc00.0700) and we have the VLANs (1, 2, 3 and 4), this means that the Bridge IDs for those 4 VLANs  are as the following:
Bridge ID for VLAN 1: (32768 + 1).(aabb.cc00.0700)
Bridge ID for VLAN 2: (32768 + 2).(aabb.cc00.0700)
Bridge ID for VLAN 3: (32768 + 3).(aabb.cc00.0700)
Bridge ID for VLAN 4: (32768 + 4).(aabb.cc00.0700)

This means that the switch can create multiple STP instances each with unique Bridge ID even if it doesn’t support/reserve more than or even less than 64 MAC addresses because of IEEE 802.1t (Extended System ID)

Switch4#show spanning-tree bridge

Hello Max Fwd
Vlan Bridge ID Time Age Dly Protocol
---------------- --------------------------------- ----- --- --- --------
VLAN0001 32769 (32768, 1) aabb.cc00.0700 2 20 15 ieee 
VLAN0002 32770 (32768, 2) aabb.cc00.0700 2 20 15 ieee 
VLAN0003 32771 (32768, 3) aabb.cc00.0700 2 20 15 ieee 
VLAN0004 32772 (32768, 4) aabb.cc00.0700 2 20 15 ieee 
Switch4#

We can see in the previous figure that Bridge priority for VLAN 1 is (32768 , 1) or (32768 + 1) or 32769 and has Bridge ID = 32769.aabb.cc00.0700,
VLAN 2 has Bridge ID = 32770.aabb.cc00.0700,
VLAN3 has Bridge ID = 32771.aabb.cc00.0700
VLAN4 has Bridge ID = 32772.aabb.cc00.0700
This means that the switch creates 4 unique Bridge IDs, as well it can creates 100 unique Bridge IDs although the switch doesn’t support/reserve more than or even less than 64 MAC addresses.

 

It seems that the issue of using STP/CST can be solved by using one of the STP modes either PVST or PVST+, as this allows the switch to create multiple STP instances (one per each VLAN), hence each STP instance has its own topology and its database and data structures, so by some modifications we can adjust the topology of each STP instance as needed.

What is the difference between PVST and PVST+ ? the PVST is used by the switch when the trunking/encapsulation protocol between the switches is Inter-Switch Link (ISL), this means that the PVST is the Cisco proprietary implementation of Per VLAN Spanning Tree, as the ISL is a Cisco proprietary trunking/encapsulation protocol, while the PVST+ is used by the switch when the trunking/encapsulation protocol between the switches is the Dot1Q (IEEE 802.1q), this means that the PVST+ is the standard implementation of Per VLAN Spanning Tree, as the 802.1q is an IEEE trunking/encapsulation protocol.

The operation of the PVST and PVST+ is exactly the same as STP/CST, but the only difference is regarding the number of created STP instances by the switch, at which the switch creates multiple STP instances (one STP instance per VLAN) and each VLAN has its own topology (the topology maybe the same) when running PVST or PVST+, while create only one STP instance for all the VLANs so that they share the same loop-free layer 2 switched network, so let’s summarize the STP/CST, PVST and PVST+ operation:

1-All switches  connected with each others and share the same STP domain should elect one among them to act as the “Root Bridge” to control the STP domain.
2-At the first each switch consider itself as the Root Bridge, so every switch send its own configuration BPDU out all the ports (This is the worst case at which all the switches generated the BPDU at the same time) and use its own Bridge ID at the Root Bridge ID field inside its configuration BPDU as the below figure:

newAll switches have default bridge priority = 32768 and have the following Bridge IDs:
Switch1 has bridge ID = 32768.1111.1111.1111
Switch2 has bridge ID = 32768.2222.2222.2222
Switch3 has bridge ID = 32768.3333.3333.3333
Switch4 has bridge ID = 32768.4444.4444.4444
Switch5 has bridge ID = 32768.5555.5555.5555
Switch6 has bridge ID = 32768.6666.6666.6666
Switch7 has bridge ID = 32768.7777.7777.7777
Switch8 has bridge ID = 32768.8888.8888.8888

Based on the assumed Bridge ID value, we can conclude that Bridge ID of switch1 is the lowest numerical value, hence Switch1 is elected as the “Root Bridge”, as well we consider all the links have the same cost.
3-The other switches no longer consider themselves as the Root bridge, hence no longer send their own configuration BPDU.
4-Every switch determine which port is the Root port that has the  best path to reach the Root bridge, then forward/relay the Superior BPDU (configuration BPDU generated by Switch1) out their Designated ports toward the non-designated switches. The switches received the BPDU with certain age (Message age value) and before forward/relay the BPDU, it increase the Message age by one, as this value represents the age of the BPDU inside the STP domain as the following figure:

new - Copy

This figure shows the direction of forwarding/relaying the Superior BPDU that is generated by the Root bridge (Switch1), as well indicates that Switch1 generate the BPDU with Message age = 0, once the switches (Switch2, 3 and 4) receive the BPDU, they adjust the Message age to be 1 and forward/relay it out their designated ports, once Switch6 receive the BPDU, it adjust the Message age to be 2 and forward it toward Switch8, this means that when the switch receive the BPDU from its Root port, it increases the Message age by one and forward/relay it out its designated ports to the downstream non-designated switches.
5-The following figure shows the resulting loop-free layer 2 switched network:

new - new

6-The Root bridge periodically send the Configuration BPDU every Hello interval (2 seconds by default), as well every switch receive the configuration BPDU on its root port, increase the Message age value by one and forward/relay it out all its designated ports.
7-If the switch didn’t receive the configuration BPDU after certain interval (actually = Max Age – Message Age), as an example Switch2, 3 and 4 receive the configuration BPDU with Message age = 0 and Max age = 20, this means that if Switch2, 3 or 4 didn’t receive the configuration BPDU after 20 – 0 = 20 seconds, they consider the Superior BPDU no longer valid on the current root port, hence they start re-converge to check which switch is the new Root bridge and adjust the roles and status of its port, as well if Switch5, 6 or 7 didn’t receive the configuration BPDU  after 20 – 1 = 19 seconds, they consider the Superior BPDU no longer valid on the current root port and so on.

The following figures show the configuration BPDU when we use PVST+ and the switch has 3 VLANs (to distinguish the difference between STP/CST and PVST+):
1-Configuration BPDU destined to the destination MAC address (01:80:c2:00:00:00) for backward compatibility with the other switches that still use STP/CST:

cst

2-Configuration BPDU destined to the destination MAC address (01:00:0c:dd:dd:cd) for PVST+ for VLAN 1 that has 802.1q tag with VLAN ID 1 and the BPDU itself has certain TLV (Type, Length and Value) (PVID) used to identify the VLAN ID this BPUD belongs to:

pvst+1

3-Configuration BPDU destined to the destination MAC address (01:00:0c:dd:dd:cd) for PVST+ for VLAN 2 that has 802.1q tag with VLAN ID 2 and the BPDU itself has certain TLV (Type, Length and Value) (PVID) used to identify the VLAN ID this BPUD belongs to:

pvst+2

4-Configuration BPDU destined to the destination MAC address (01:00:0c:dd:dd:cd) for PVST+ for VLAN 3 that has 802.1q tag with VLAN ID 3 and the BPDU itself has certain TLV (Type, Length and Value) (PVID) used to identify the VLAN ID this BPUD belongs to:

pvst+3

This means that when the switch run PVST or PVST+ and has 3 VLANs, it generates 4 configuration BPDUs, one for the backward compatibility  with the STP/CST domains (untagged) destined to the MAC address (01:80:c2:00:00:00) and three BPDUs and each one tagged with the correct VLAN and destined to the MAC address (01:00:0c:dd:dd:cd).

 

Note: Even if the STP domain become stable and no failure/changes happened in the domain, the STP process on all the switches still running and never stop, this means that every switch receive the configuration BPDU and make its calculations again and again to know again and again which port is the root, designated and non-designated, so don’t be fooled because of the STP stability and said that the STP stops its calculations, in reality the STP never stops.

What about the changes happen in the STP domain ?

The STP should have certain criteria that handle/deal with the changes that can happen in its domain, so what is the meaning of changes from STP point of view ?
1-Port transition from Blocking to Forwarding (of course through Listen and Learn states).
2-Port transition from Forwarding to Blocking.
3-The Root bridge changed in the STP domain.
4-Receive Topology Change Notification (TCN )BPDU is received from downstream switch on designated port.

So let’s check the steps should be followed by the switches when change detected in the STP domain:
1-Once one of the previous conditions/changes happened at any switch in this STP domain, this switch that detected the change generate Topology Change Notification (TCN) BPDU and send it out its Root port (i.e toward the Root bridge) to notify it about that change as it has no way to to notify all the switches within the STP domain, so that the Root bridge can notify all the other switches within the STP domain, as this failure may cause disruption in the communication between the devices that communicate over this switched network, so assume the failure in the following topology:

new TCN

2-Once the failure happened at the Link between Switch6 and Switch8, Switch6 generate TCN BPDU and send it to Switch2 out its Root port toward the Root bridge (Switch1).The following figure shows this TCN BPDU as seen on Wireshark:

tcn wireshark1

3-Switch2 received the TCN BPDU, then it should acknowledge this BPDU by sending Topology Change Acknowledge (TCA) BPDU back to Switch6. The following figure shows this TCA BPDU as seen on Wireshark:

tca wireshark14-Switch2 forward/relay the TCN BPDU to Switch1 out its root port toward the Root bridge (Switch1). The following Figure shows this TCN BPDU as seen on Wireshark:

tcn wireshark2

5-Switch1 (Root Bridge) acknowledge this BPDU by sending TCA BPDU back to Switch2. The following figure shows this TCA BPDU as seen on Wireshark:

tca wireshark2

6-Switch1 should notify all the other switches within the STP domain by generating its own TC configuration BPDU and send it downstream to Switch2, Switch3 and Switch4 out all its designated ports and still send for (Max Age + Forward Delay) seconds = 35 seconds and this is used to force the switches to early expire or age out the unused MAC entries inside the CAM table as this failed link may result in some frames to be dropped as the destination MAC addresses maybe known via this failed link, hence this result in the frames known via this failed link to be dropped. The following figure shows this TCN BPDU as seen on Wireshark (i mention only the BPDU sent to Switch3, no need to mention all of them as they are exactly the same except for the Sender Port ID):

tcn wireshark3

7-The other switches (Switch2, Switch3 and Switch4) forward/relay the TCN BPDU downstream to Switch5, Switch6 and Switch7 out all its designated ports. The following figure shows this TC configuration BPDU as seen on Wireshark (i mention only the BPDU sent to Switch6, no need to mention all of them as they are exactly the same except for the Sender Port ID):

tcn wireshark4

The purpose of sending the TC configuration BPDU for (Max Age + Forward Delay) seconds = 35 seconds  is to force the switches to early expire or age out the unused MAC entries inside the CAM table as this failed link may result in some frames to be dropped as the destination MAC addresses maybe known via this failed link, hence this result in the frames known via this failed link to be dropped.

Let’s verify the number of BPDUs sent and received by or on the switchport on the Root bridge and one of the non-root bridges, as well the number of topology changes happened in the topology from CLI point of view:

Switch1 (Root Bridge):

Switch1#show spanning-tree interface Ethernet0/0 detail 
 Port 1 (Ethernet0/0) of VLAN0001 is designated forwarding 
 Port path cost 100, Port priority 128, Port Identifier 128.1.
 Designated root has priority 32769, address aabb.cc00.0100
 Designated bridge has priority 32769, address aabb.cc00.0100
 Designated port id is 128.1, designated path cost 0
 Timers: message age 0, forward delay 0, hold 0
 Number of transitions to forwarding state: 1
 Link type is shared by default
 BPDU: sent 295, received 4
Switch1#

The previous figure shows STP details about the port Eth0/0 such as:
1-The port is Designated/Forwarding.
2-The Port Cost is 100, Port priority is 128 , Port ID is 128.1
3-The Designated Root Bridge ID is 32769.aabb.cc00.0100
4-The Designated bridge ID has the same value as Root Bridge ID because this switch is the Root Bridge.
5-Timers: Message age = 0 as this switch is the Root bridge, Forward delay  = 0 as this port right now in Forwarding state hence the Forward delay timer is not active at the moment and hold time = 0 as this time represent the min number of seconds between each BPDU sent on the port.
6-The link transit to forwarding state only one time.
7-the link type is Shared by default as the port is half-duplex which is designed to connect this port to multiple devices at the same time so it is shared.
8-The number of sent (295) and received(4) BPDUs.

Switch1#show spanning-tree detail

VLAN0001 is executing the ieee compatible Spanning Tree protocol
 Bridge Identifier has priority 32768, sysid 1, address aabb.cc00.0100
 Configured hello time 2, max age 20, forward delay 15
 We are the root of the spanning tree
 Topology change flag not set, detected flag not set
 Number of topology changes 6 last change occurred 00:09:33 ago
 from Ethernet0/1
 Times: hold 1, topology change 35, notification 2
 hello 2, max age 20, forward delay 15 
 Timers: hello 0, topology change 0, notification 0, aging 300
 --More--

The previous figure shows some details about STP for VLAN1 such as:
1-VLAN 1 is running IEEE compatible STP/CST.
2-Bridge ID consists of three parts bridge 32786, System ID == VLAN ID = 1 and MAC address aabb.cc00.0100.
3-This switch is the Root bridge.
4-Topology change flag not set as no change happened to the topology at the moment.
5-There are 2 topology changes happened 9 min and 33 seconds ago
6-Hold time is 1 second, topology change time is 35 seconds (Max Age + Forward Delay) as mentioned before, notification time is 2 seconds.
7-Hello timer is 2 seconds, Max age timer is 20 seconds and Forward delay timer is 15 seconds.

Switch3 (Non-Root Bridge):

Switch3#show spanning-tree interface Ethernet0/0 detail 
 Port 1 (Ethernet0/0) of VLAN0001 is root forwarding 
 Port path cost 100, Port priority 128, Port Identifier 128.1.
 Designated root has priority 32769, address aabb.cc00.0100
 Designated bridge has priority 32769, address aabb.cc00.0100
 Designated port id is 128.1, designated path cost 0
 Timers: message age 1, forward delay 0, hold 0
 Number of transitions to forwarding state: 1
 Link type is shared by default
 BPDU: sent 4, received 295
Switch3#

 

STP Basic Configurations:

You can configure PVST as the STP mode using the following command(default mode is PVST):

Switch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#spanning-tree mode pvst 

You can enable the 802.1t Extended System ID using the following command(default is enabled):

Switch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#spanning-tree extend system-id

You can change the method used to choose the best path either based on “short” or “long” path using the following command (default is short):

Switch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#spanning-tree pathcost method short 
Switch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#spanning-tree pathcost method long

You can change the Hello, Forward delay and Max age timer per VLAN using the following commands (default hello = 2, Forward delay = 15 and Max age = 20):

Switch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#spanning-tree vlan 1 hello-time 4 
Switch1(config)#spanning-tree vlan 1 forward-time 20 
Switch1(config)#spanning-tree vlan 1 max-age 30

You can change the Per-VLAN Bridge Priority  but the priority value must be multiple of 4096 and this is because the Extended System ID is enabled, this means that you can configure the priority to be 0, 4096, 8192, 12288, …. As well you can configure it either as the primary or the secondary Root Bridge using the following commands (default Bridge priority = 32768) :

Switch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#spanning-tree vlan 1 priority 12288
Switch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#spanning-tree vlan 1 root secondary
Switch1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch1(config)#spanning-tree vlan 1 root primary

When you configure the switch as the secondary Root, this automatically set the priority to 28672, while if you configure it as the primary Root, this automatically set the priority to 24576.

You  can change the Cost of the port for all the VLANs, or you can change it per-VLAN using the following command:

Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#interface Ethernet0/1
Switch2(config-if)#spanning-tree cost 50
Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#interface Ethernet0/1
Switch2(config-if)#spanning-tree vlan 1 cost 40

You can change the Port Priority for all the VLANs, or you can change it per-VLAN, but the value must be multiple of 64 using the following command (default Port priority = 128):

Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#interface Ethernet0/1
Switch2(config-if)#spanning-tree port-priority 64
Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#interface Ethernet0/1 
Switch2(config-if)#spanning-tree vlan 1 port-priority 64

You can configure the link-type to be either shared or point-to-point using the following command:

Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#interface Ethernet0/1
Switch2(config-if)#spanning-tree link-type shared 
Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#interface Ethernet0/1
Switch2(config-if)#spanning-tree link-type point-to-point

 

Let’s talk about the STP features (PortFast, UplinkFast and BackboneFast) supported by Cisco IOS to make some improvements in the STP operation and convergence.

1-PortFast:

As mentioned before, for the port to transit from Blocking to Forwarding it takes 30 seconds (2×15 seconds) as it transition from Blocking to listen in no time, from Listen to Learn takes Forward delay (15 seconds), then from Learn to Forward takes another Forward delay (15 seconds), hence the total to transit from Block to Forward takes 15 + 15 = 30 seconds. Actually this delay is sometimes huge, specially when this happened for the ports connected to normal PCs or Laptops that don’t run STP at all, so the Loop is supposed to not happen at those ports, for this reason we need something allow the switch to move the port immediately  from Block to Forward without waiting the 30 seconds, actually the feature that can make this is the PortFast feature which is Cisco proprietary. The PortFast feature provide two good things:
1-It allow the switch to move the port (where PortFast is enabled) immediately  from Block to Forward without waiting the 30 seconds, this means that if the PC is already connected to the port, but for any possible reason the port is disconnected and connected again, the switch will not require 30 seconds to transit from Block to Forward.
2-If the port is disconnected, the switch will send TCN BPDU because of this disconnection as it consider it as change in the STP topology, hence this results in the flooding of unwanted TC configuration BPDU by the Root bridge and unwanted flushing , expiring or aging out the MAC entries in the CAM table, as this can result in some unknown unicast flooding because the MAC addresses of these unicast frames maybe flushed from the CAM table, so the PortFast solved this problem as well, at which if the port that is configured PortFast flapped for any possible reason, the STP doesn’t generate TCN BPDU because of this disconnection.

The PortFast can be configured globally on all the ports using the following command (PortFast is not enabled by default):

Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#spanning-tree portfast default 
%Warning: this command enables portfast by default on all interfaces. You
 should now disable portfast explicitly on switched ports leading to hubs,
 switches and bridges as they may create temporary bridging loops.

Switch2(config)#

You can configure PortFast per port either on access or trunk ports using the following commands:

Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#interface Ethernet0/3
Switch2(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 Ethernet0/3 but will only
 have effect when the interface is in a non-trunking mode.
Switch2(config-if)#
Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#interface Ethernet0/1
Switch2(config-if)#spanning-tree portfast trunk 
%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

Switch2(config-if)#

2-UplinkFast:

The UplinkFast is a Cisco proprietary feature that is used to track the Root Port, so that if the Root Port failed for any possible reason, it choose the next best path to the Root Bridge which is reachable via one of the Alternate ports and make it in Forwarding state immediately without taking long time before transiting from Block to Forward, and it is used on the Access switches. When the UplinkFast is enabled on the Access switch it does the following actions to avoid some issues:
1-It automatically set the Bridge priority to 49152.
2-It automatically set the port cost to 3000.
The UplinkFast feature make these two changes so that this switch become unlikely eligible to become Root switch or Designated switch to another downstream switch, this means that the UplinkFast want the switch to act as standalone switch, hence it has one Root Port, and all the other ports connected to another switches are Alternate except for the host ports (where normal host are connected) are Designated.
3-The UplinkFast force the switch to flush or expire all the MAC entries known via the failed Root port, as well to send dummy multicast frames sourced from each of the local MAC addresses (i.e the MAC addresses known via the host ports), so that the upstream switches update their CAM table for these MAC addresses to be known via the new Root port.

The UplinkFast feature can be configured using the following command (UplinkFast is disabled by default):

Switch6#conf 
Enter configuration commands, one per line. End with CNTL/Z.
Switch6(config)#spanning-tree uplinkfast

You can verify that the UplinkFast is enabled using the following command:

Switch6#show spanning-tree uplinkfast 
UplinkFast is enabled

Station update rate set to 150 packets/sec.

UplinkFast statistics
-----------------------
Number of transitions via uplinkFast (all VLANs) : 0
Number of proxy multicast addresses transmitted (all VLANs) : 0

Name Interface List
-------------------- ------------------------------------
VLAN0001 Et1/0(fwd), Et0/3, Et1/1
VLAN0002 Et1/0(fwd), Et0/3, Et1/1
VLAN0003 Et1/0(fwd), Et0/3, Et1/1
VLAN0004 Et1/0(fwd), Et0/3, Et1/1
Switch6#

Here the show command displays the following details:
1-The UplinkFast is enabled.
2-The Switch can send dummy multicast frames sourced from the local MAC addresses with rate up to 150 Packets per second.
3-UplinkFast Statistics shows that there are no transitions happened from one Root Port to another for any of the configured VLANs, as well no dummy multicast frames are sent by the switch for any of the configured VLANs.
4-Interface List shows the current Root Port which is the port with the (fwd) state, while the other interfaces are the Alternate ports for each VLAN.

 

3-BakcboneFast:

This feature is used by Cisco IOS to help in converging the STP domain in case of failure , but the failure here is indirect, assume that we have the following topology but still we don’t enable BackBoneFast feature to explain why we need the BackboneFast and its operation:

new - new - Copy

Let’s check what happened or should happen in sequence:
1-Switch2 detects that there is a failure happened at the port Eth0/1, hence it cause the link between Sw2 and Sw1 to fail, as well this failure is considered as direct failure from Switch2 point of view.
2-Switch2 has no valid path to the Root bridge (Switch1), for this reason it start to generate configuration BPDU considering itself as the new Root Bridge and send it to Switch3 out the port Eth1/2.
3-Switch3 received the configuration BPDU on the port Eth1/2, but it consider it as inferior BPDU as it already stored superior BPDU at this port (has Root Bridge of Switch1), so the default behavior it neglect it, but it still waiting for the superior BPDU to be received again, but after the Max age expired for the superior BPDU, it consider that the switch connected to that port has no superior info about the Root bridge, hence it put its port at Listening state and send the superior BPDU that it know from Switch 1 via port Eth0/0.

This means that Switch2 know again path to the Root Bridge (Switch1) after Max Age timer = 20 seconds, this means that the traffic dropped during this time, so to avoid such behavior, we can use the BackboneFast Feature.

How the BackboneFast Feature works ?

Let’s see how the BackboneFast Feature works by checking the same topology to describe its operation after enabling the BackboneFast feature at all the switches (this is a must):

new - Copy

1-Switch2 detects that there is a failure happened at the port Eth0/1, hence it cause the link between Sw2 and Sw1 to fail, as well this failure is considered as direct failure from Switch2 point of view.
2-Switch2 has no valid path to the Root bridge (Switch1), for this reason it start to generate configuration BPDU considering itself as the new Root Bridge and send it to Switch3 out the port Eth1/2.
3-Switch3 know that the received BPDU is inferior to the stored at this port, hence it use the BackboneFast feature by sending Root Link Query (RLQ) request message toward its upstream switches (Switch1 at our case) requesting if this upstream switch has info about the Root Bridge.
4-Switch1 (The Root Bridge) receive this RLQ request message and respond by sending RLQ response message telling the querier (Switch3) that it is the Root bridge and it is valid.
5-Switch3 send the superior BPDU it know via its Root Port Eth0/0 to Switch2 immediately without waiting the Max age timer to expire so this save time.

The BackboneFast feature can be configured using the following command (BackboneFast is disabled by default):

Switch2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch2(config)#spanning-tree backbonefast

You can verify that the BackboneFast is enabled using the following command:

Switch2#show spanning-tree backbonefast 
BackboneFast is enabled

BackboneFast statistics
-----------------------
Number of transition via backboneFast (all VLANs) : 0
Number of inferior BPDUs received (all VLANs) : 0
Number of RLQ request PDUs received (all VLANs) : 0
Number of RLQ response PDUs received (all VLANs) : 0
Number of RLQ request PDUs sent (all VLANs) : 0
Number of RLQ response PDUs sent (all VLANs) : 0
Switch2#

Here the show command displays the following details:
1-The BackboneFast is enabled.
2-There are no any transitions happened via the BackboneFast feature for any VLAN.
3-There are no inferior BPDUs received for any VLAN.
4-There are no RLQ request received for any VLAN.
5-There are no RLQ response received for any VLAN.
6-There are no RLQ request sent by this switch for any VLAN.
7-There are no RLQ response sent by this switch for any VLAN.

 

Let’s talk about other features supported by Cisco IOS used to protect against some violations that can affect your STP domain:

1-BPDU Guard:

The BPDU guard feature is used by the access switch and configure it on the host ports, this means that we configure the BPDU guard feature under the ports where the host/end users are connected, as it is supposed that those ports shouldn’t receive BPDU from those connected devices  as they are just end-users and for sure will not send BPDU.so if the switch receive BPDU on this port, it will put it in err-disable, this means that it is disabled (logical shutdown), but you can solve this issue by either bounce the port (i.e make shut then unshut) or by configuring the switch to make auto-recovery for the BPDU guard after certain time, so that if it received BPDU on the port, it make it logical shutdown, then it try to recover (unshut) it after configurable timer.

The BPDU guard feature can be configured on the ports using the following command (BPDU guard is disabled by default):

Switch6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch6(config)#interface Ethernet1/2
Switch6(config-if)#spanning-tree bpduguard enable

You can verify that the BPDU Guard feature is enabled under the port using the following command:

Switch6#show spanning-tree interface Ethernet1/2 detail 
 Port 7 (Ethernet1/2) of VLAN0001 is designated forwarding 
 Port path cost 3100, Port priority 128, Port Identifier 128.7.
 Designated root has priority 32769, address aabb.cc00.0100
 Designated bridge has priority 49153, address aabb.cc00.0d00
 Designated port id is 128.7, designated path cost 3140
 Timers: message age 0, forward delay 0, hold 0
 Number of transitions to forwarding state: 1
 Link type is shared by default
 Bpdu guard is enabled
 BPDU: sent 18768, received 0
Switch6#

We can see at this output that the BPDU guard is enabled at this port.

 

2-Root Guard:

The Root Guard feature is used by the switch to protect the design of the STP domain to be safe from any rogue switch that can change in the topology and make problems or sub-optimal switching, this means that if the port is configured with Root Guard and it received superior BPDU (i.e BPDU better than the current one), the switch  put the port in Root-inconsistent state, which means that the location of the Root bridge is not synchronized between the two switches, because you know that the Root bridge is located at another location rather than behind this port, so the two switches are in inconsistent state regarding the Root bridge location.

The Root guard feature can be configured on the port using the following command (Root guard is disabled by default):

Switch6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch6(config)#interface Ethernet1/2 
Switch6(config-if)#spanning-tree guard root 
Switch6(config-if)#
*Jan 1 21:48:42.316: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port Ethernet1/2.

You can verify that the Root Guard feature is enabled under the port using the following command:

Switch6#show spanning-tree interface Ethernet1/2 detail 
 Port 7 (Ethernet1/2) of VLAN0001 is designated forwarding 
 Port path cost 3100, Port priority 128, Port Identifier 128.7.
 Designated root has priority 32769, address aabb.cc00.0100
 Designated bridge has priority 49153, address aabb.cc00.0d00
 Designated port id is 128.7, designated path cost 3140
 Timers: message age 0, forward delay 0, hold 0
 Number of transitions to forwarding state: 1
 Link type is shared by default
 Root guard is enabled on the port
 BPDU: sent 4126, received 0
Switch6#

We can see at this output that the Root guard is enabled at this port.

3-BPDU filter:

The BPDU filter feature is used by the switch to not send  BPDU out host ports, for sure the end-users connected to the host ports will not participate in the STP domain, hence they will not send BPDU and don’t need the BPDU sent by the switch, so we need to filter the BPDU out these host ports to save processing and memory.

The BPDU filter feature can be configured on the port using the following command (BPDU filter is disabled by default):

Switch6#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch6(config)#interface Ethernet1/2
Switch6(config-if)#spanning-tree bpdufilter enable

You can verify that the BPDU filter feature is enabled under the port using the following command:

Switch6#show spanning-tree interface Ethernet1/2 detail 
 Port 7 (Ethernet1/2) of VLAN0001 is designated forwarding 
 Port path cost 3100, Port priority 128, Port Identifier 128.7.
 Designated root has priority 32769, address aabb.cc00.0300
 Designated bridge has priority 49153, address aabb.cc00.0c00
 Designated port id is 128.7, designated path cost 3100
 Timers: message age 0, forward delay 0, hold 0
 Number of transitions to forwarding state: 1
 Link type is shared by default
 Bpdu filter is enabled
 BPDU: sent 4234, received 0
Switch6#

We can see at this output that the BPDU filter is enabled at this port.

4-Loop Guard:

The Loop guard is a feature used by the switch to avoid Loop from happening in case of unidirectional link detected on upstream port (i.e Root Port or Alternate port), actually the Non-Root bridge receive the superior BPDU from the Root port and Alternate port, the issue is when there is unidirectional is detected on the Root port or the Alternate ports, the Switch no longer receives the superior BPDU, so it wait after Max age to expire before it declare that the superior BPDU expired on this port and at this point the switch needs to transit this port from  Alternate to designated and this can cause the traffic to be exchanged in the two directions, hence the loop happened again and this because the switch transit the Alternate port into Designated and caused the traffic to loop in the network. The Loop guard is used to solve such issue, at which the Loop guard think that if suddenly the BPDU no longer received neither on the Root port nor the Alternate port, this means that something wrong happened, and this wrong thing is maybe the upstream switches have problem with their physical connection with this switch, so this caused the unidirectional issue to happen, so it is better not to transit the ports (Root and Alternate) to designated and we should block them as in the future maybe the issue get solved and this can result in loop, for this reason the Loop Guard put the port in “Loop-inconsistent” state once the superior BPDUs expired after the Max age expired to avoid transiting them into Designated role, and Loop-inconsistent means that this switch and the other switches that have unidirectional link are not synchronized with each others regarding cutting or blocking the possible loop, for this reason they are in inconsistent state regarding how to cut/block the Loop.

The Loop Guard feature can be configured either globally or per port using the following command (Loop guard is disabled by default):

Switch5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch5(config)#spanning-tree loopguard default
Switch5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch5(config)#interface Ethernet0/0
Switch5(config-if)#spanning-tree guard loop

You can verify that the Loop Guard feature is enabled under the port using the following command:

Switch5#show spanning-tree interface Ethernet0/0 detail 
 Port 1 (Ethernet0/0) of VLAN0001 is root forwarding 
 Port path cost 3100, Port priority 128, Port Identifier 128.1.
 Designated root has priority 32769, address aabb.cc00.0100
 Designated bridge has priority 32769, address aabb.cc00.0300
 Designated port id is 128.1, designated path cost 40
 Timers: message age 2, forward delay 0, hold 0
 Number of transitions to forwarding state: 1
 Link type is shared by default
 Loop guard is enabled on the port
 BPDU: sent 6, received 4380
Switch5#

We can see at this output that the Loop Guard is enabled at this port.

 

5-Unidirectional Link Detection (UDLD):

The UDLD is a feature used by the switch to avoid Loop from happening in case of unidirectional link detected. The UDLD use its own message to establish UDLD neighborship  between the two switches on the link that may face unidirectional. Each switch send its UDLD echo message carrying its own ID and the sender port ID (interface name not the STP Port ID), as well the neighbor’s switch ID and its port ID that it see on this link and carry it inside a list of neighbors detected or seen on this link. The UDLD has two modes, either “normal mode” or “aggressive mode. The switch can face two scenarios, either detect actual unidirectional on this link or can’t detect actual unidirectional but it didn’t receive the UDLD echo message from its neighbor anymore, at the first scenario (i.e it detects actual unidirectional on the link) if the switch either runs normal or aggressive mode,  it immediately put this unidirectional link in err-disable, while at the second scenario (i.e it can’t detect actual unidirectional but it didn’t receive the UDLD echo message from its neighbor anymore) if the switch runs normal mode and it didn’t receive the UDLD echo message from its neighbor, it will try to establish the UDLD neighborship with this neighbor 8 times, and if failed, it will not do anything, while if it runs aggressive mode, it will try to establish the UDLD neighborship with this neighbor 8 times, and if failed, it will put the interface in err-disable.

The UDLD feature can be configured either globally or per port using the following command (UDLD is disabled by default):

Switch5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch5(config)#udld enable
Switch5#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Switch5(config)#interface Ethernet0/0
Switch5(config-if)#udld port

You can verify that the UDLD feature is enabled under the port using the following command:

Switch5#show udld

Interface Et0/0
---
Port enable administrative configuration setting: Enabled
Port enable operational state: Enabled
Current bidirectional state: Unknown
Current operational state: Advertisement
Message interval: 7000 ms
Time out interval: 5000 ms
 
 --More--

 

We can see at the following from this output:
1-UDLD is configured at the port Eth0/0.
2-UDLD is operational at the port Eth0/0.
3-The current bidirectional state is Bidirectional which indicates that it is ok.
4-The switch detected only one neighbor on this port.
5-Message interval is 15 seconds.
6-Message timeout is 5 seconds.

The following figure shows the UDLD echo message as seen on Wireshark:

udld

1-Device ID = 67108877, indicates the ID of the sender of this UDLD echo message.
2-Port ID = Eth0/0, indicates that sender port is Ethernet0/0.
3-The Echo field carry the neighbor’s ID and its port ID (Ethernet0/0 not the STP Port ID).
4-Message interval field carry the interval at which the message is sent in a periodic way.
5-Timeout interval field carry the time out value used to determine when the unidirectional is detected.
6-Device name field carry the name of the device sending this UDLD echo message.
7-Sequence number field carry the seq number sent by this switch and is used to keep track of the UDLD echo messages exchanged between the two switches.

I will talk about RSTP and MST in the next post.

 

Hope that the post is helpful.

Regards

Mostafa Hamza

3 thoughts on “2-R&S/Spanning Tree Protocol (STP) Part 2.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s