End to End propagation delay computation for STP

Question

While reading a bunch of details about STP timers on this Cisco website https://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/19120-122.html#f1

I could not understand how they ended up with the formula for end to end propagation delay.

Here is the formula from the website

End-to-end BPDU propagation delay—This value is the amount of time that is necessary for a BPDU to travel from one end of the network to the other end. Assume a diameter of seven hops, three BPDUs that can be lost, and a hello time of 2 sec. In this case, the formula is:

End-to-end_BPDU_propa_delay
= ((lost_msg + 1) x hello) + ((BPDU_Delay x (dia – 1)) 
= ((3 + 1) x hello) + ((1 x (dia – 1)) 
= 4 x hello + dia – 1 
= 4 x 2 + 6 
= 14 sec

I dont get how the lost BPDUs influence the formula. They assume we could lost BPDUs but how those BPDUs are recovered actually? Since there is only Ethernet frame, there is no recovery option.

Imagine the following network diagram

(SW1)--(SW2)--(SW3)--(SW4)

SW1 starts sending Hello BPDU (because its interface has been activated let's say. The interface will be in LISTENING status right after sending its BPDUs.

Here is my question: If the BPDU got lost between SW2 and SW3; it will never reach SW4. But SW1 will still changes its LISTENING states to LEARNING after the normal forward delay independantly from the BPDU loss! Thus, the SW1 could learn "corrupted" mac addresses as SW4 is not aware of the topology change and there is no recovery mean. If there is no recovery mean; why the "official" formula includes several packet loss (as if one loss could be recovered by the next BPDU generation)?

What did I got wrong here?

Thank you for your time and expertise,

Answer 1

Lost BPDUs simply stay lost, they are not recovered. Instead, the next hello interval sends out a fresh BPDU which continues to propagate link states. So, when a BDPU is lost an additional hello interval is required to cross the network.

Also, BPDUs are not forwarded. Each switch produces its own BPDUs and only sends them to its direct neighbors. STP BPDUs use multicast addressing that is not forwarded by 802.1D-compliant bridges. Even though the frames themselves are not forwarded, their information is carried on.

As you point out, the longish delay for spanning tree reconvergence was a problem with the original (and obsolete) 802.1D STP implementation. The later protocol versions RSTP and MSTP react much faster to topology changes by explicitly propagating those.

Still, the propagation delay may be a problem with a "deep" network - a very good reason to design a network with a small diameter for the data link layer in mind.

Accordingly, do not chain switches but always use a hierarchical design: (collapsed) core ⇔ access. For a large network with a full hierarchy, core ⇔ distribution ⇔ access, use routing at least between core and distribution. Multipath routing can handle redundant links much better than STP.