cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3176
Views
0
Helpful
4
Replies

MST/RSTP max latency between two switches

Hi all, I think this is a simple question but I can´t find the answer, yet!

In a RSTP or MST enviroment, BPDUs are used as keepalives in point-to-point links. Correct ?? So if three consecutives BPDUs are lost, we can assume the path between the two switches is down. The question is: which is the time the switch receiving BPDUs waits before considering one BDPU lost ?? It is the hello interval ??

I´am looking for this answer to know which is the maximum latency supported between two switches running RSTP or MST.

Thanks!

Regards,

Max

1 Accepted Solution

Accepted Solutions

Hello Max,


You are welcome.

I am agree with you about the theory. I just want to add just as the previous link stated that unlike STP 802.1D, in 802.1w BPDU are sent out every switch port every hello-time (thus inside 802.1s region), and not simply relayed anymore (regardless of whether BPDUs are received from the root).

In this way, any switch anywhere in the network can play an active role in maintaining the topology.

Otherwise an intersting document of STP timers considerations (with aspects like "message-age" for the exact calculation of the max-age formula etc ..) is at the following link : http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml

BUT as this link states the document only discusses how to tune STP timers for regular 802.1D (not 802.1w/802.1s).

===================================

With that being said, after having checked the IEEE standard for RSTP  (http://standards.ieee.org/getieee802/download/802.1D-2004.pdf)

I have seen there is likely an underlying timer "rcvdInfoWhile" which should track the BPDU reception and refresh the timer each time it receives a BPDU =>

17. Rapid Spanning Tree Protocol (RSTP) /*/ 17.17 State machine timers /*/  17.17.6 rcvdInfoWhile

rcvdInfoWhile / The Received Info timer => The time remaining before the spanning tree information received by this Port [portPriority (17.19.21) and portTimes (17.19.22)] is aged out if not refreshed by the receipt of a further Configuration Message (check schema in attachments).

Hope it helps..

Best regars.

Karim

View solution in original post

4 Replies 4

krahmani323
Level 3
Level 3

Hello Max,

The answers to your questions are yes, the hello-time sets the interval in which a bridge expects to hear a hello relayed from its neighboring bridges

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml#topic4 =>

On a given port, if hellos are not received three consecutive times,       protocol information can be immediately aged out (or if max_age expires).

Because of the previously mentioned protocol modification, BPDUs are now used       as a keep-alive mechanism between bridges.

A bridge considers that it loses       connectivity to its direct neighbor root or designated bridge if it misses       three BPDUs in a row  => 3 x hello-time (default is 2 seconds) = 6 seconds (default)..

Depending on the STP mode you are running there is a command (along with other STP timers) to change this value : spanning-tree [vlan vlan-id | mst] hello-time seconds (but only under controlled circumstances).

Hope it helps.

Regards

Karim

Thanks for your response!

I have read this document, and now I think that the "key" word in that explanation is "...in a row..". I was confused because I was thinking about a timeout for every BPDU, so I supposed that the port receiving BPDUs (root port, for example) had to start a hello timer every time a BPDU was received from its neighboring switch, but this argument is not very solid.

Now, if I think that every time a BPDU is received, the switch starts a (3 * hello) timer, and that expects to receive, at least, one BPDU per interval; this could be a good theory. Am I right ?? This is the way that the keepalive mechanism whith BPDU works ?

Thanks again.

Regards,

Maxi

Hello Max,


You are welcome.

I am agree with you about the theory. I just want to add just as the previous link stated that unlike STP 802.1D, in 802.1w BPDU are sent out every switch port every hello-time (thus inside 802.1s region), and not simply relayed anymore (regardless of whether BPDUs are received from the root).

In this way, any switch anywhere in the network can play an active role in maintaining the topology.

Otherwise an intersting document of STP timers considerations (with aspects like "message-age" for the exact calculation of the max-age formula etc ..) is at the following link : http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml

BUT as this link states the document only discusses how to tune STP timers for regular 802.1D (not 802.1w/802.1s).

===================================

With that being said, after having checked the IEEE standard for RSTP  (http://standards.ieee.org/getieee802/download/802.1D-2004.pdf)

I have seen there is likely an underlying timer "rcvdInfoWhile" which should track the BPDU reception and refresh the timer each time it receives a BPDU =>

17. Rapid Spanning Tree Protocol (RSTP) /*/ 17.17 State machine timers /*/  17.17.6 rcvdInfoWhile

rcvdInfoWhile / The Received Info timer => The time remaining before the spanning tree information received by this Port [portPriority (17.19.21) and portTimes (17.19.22)] is aged out if not refreshed by the receipt of a further Configuration Message (check schema in attachments).

Hope it helps..

Best regars.

Karim

Exactly!

I checked the IEEE standard and found additional information regarding this timer. Here is the procedure that is used by the variable you found:

17.21.23 updtRcvdInfoWhile()

Updates rcvdInfoWhile (17.17.6). The value assigned to rcvdInfoWhile is the three times the Hello Time, if

Message Age, incremented by 1 second and rounded to the nearest whole second, does not exceed Max Age,

and is zero otherwise. The values of Message Age, Max Age, and Hello Time used in this calculation are

taken from portTimes (17.19.22).

It confirms what we agreed on. That the timer on the receiving side, to detect a link/path/bridge/port failure in point-to-point links using RSTP, is set to 3 times de hello time.

Thanks a lot!

Regards,

Max

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco