Solved: Re: STP Diameter and Max Age Question.

Craddockc · ‎07-01-2013

Hello Community,

As I study STP and all its glorious forms (802.1D, PVST+, MST) I am beginning to question some things regarding the diameter and the default timers. From what I am reading the Cisco best practices are to make sure that a switched network diameter is not to exceed 7 switches. That is to say that a frame traversing the network end to end should not exceed 7 hops. If this is the case, then why have a max age of 20? Or in the case of MST a max hop count of 20? Why tune default STP timers to a diameter of 7 and then not age out the BPDU info until its crossed 20 seconds/switches? This makes no sense to me. I know this is more a philosophical question, but one thats bugging me nonetheless. Thanks.

Chris.

Peter Paluch · ‎07-01-2013

Hi Chris,

These are some great questions you are asking.

First of all, I assume you are familiar with this document:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml

This document very nicely explains how the individual timers in STP are calculated, based on a few assumptions about the network diameter and the speed of processes on bridges/switches, the default values being very conservative. Note how the document shows that once you make an assumption that the Hello interval is 2 seconds and the network diameter is 7 then the MaxAge can really be computed to be equal to 20 seconds.

That is to say that a frame traversing the network end to end should not  exceed 7 hops. If this is the case, then why have a max age of 20?

Because, as the document explains, for a network having the diameter of 7, it may take up to 14 seconds between two successive BPDUs as they are originated on one end of the network, possibly lost, and travel the whole diameter to the other end, plus the time reserve we need to have to not age out these BPDUs prematurely (as they will be aged out after MaxAge-MessageAge seconds in STP) which is 6, yielding a total of 20 seconds.

Or in the case of MST a max hop count of 20?

The 20 here is just a legacy value retaken from old STP. Please note that neither RSTP nor MST age out BPDUs after the MaxAge-MessageAge seconds. BPDUs in RSTP/MST age out after three consecutively lost BPDUs (3xHello). The MessageAge in RSTP is used for sanity checks - if the incoming BPDU has its MessageAge equal to or higher than the MaxAge then the BPDU is discarded right away.

MST does it similarly but in addition to MessageAge in the IST part of the BPDU (configured using spanning-tree mst max-age) that gets incremented, there is also a "CIST Remaining Hops" field in the MST Extension part of the BPDU which is set to 20 (configured by spanning-tree mst max-hops) that gets decremented, and if it drops to 0, the BPDU is also discarded.

So in RSTP and MSTP, the MaxAge is merely a sanity limit on the diameter of the switched network. It is not really a timer RSTP/MSTP would be using.

Please feel welcome to ask further!

Best regards,

Peter

View solution in original post

Peter Paluch · ‎07-02-2013

Hello Chris,

STP builds on the capability of comparing any two BPDUs to see which one is better, or superior, to the other which is considered worse, or inferior.

Two BPDUs are compared to each other by comparing the following fields from the BPDUs in the indicated succession:

Root Bridge ID (consisting of priority, VLAN, and MAC address)
Root Path Cost
Sending Bridge ID (consisting of priority, VLAN, and MAC address)
Sending Port ID (consisting of priority and port index)

Lower value wins.

You always start comparing the two BPDUs by comparing the Root Bridge ID in both BPDUs. If any of these BPDUs contains a lower Root Bridge ID, that BPDU is considered superior and the comparison stops.

If both BPDUs contain the same RBID, you proceed to compare the Root Path Cost. Again, if one of the BPDUs has a lower RPC than the other, it will be considered superior and the comparison stops.

If both BPDUs contain the same RPC, you proceed to compare the Sending Bridge ID. Again, either one of the BPDUs has the SBID value lower (in which case it is the superior BPDU), or in case the SBID is identical in both BPDUs, you proceed to compare the Sending Port ID, and again, the BPDU having the lower SPID value is considered superior.

In short, you compare two BPDUs by comparing the fields mentioned above, looking for the first inequality. The BPDU containing a lower value in the compared field is better, or superior.

Does this make any sense?

Best regards,

Peter

View solution in original post

Peter Paluch · ‎07-02-2013

Hello Chris,

Yes, the comparison of BPDUs never stops. In essence, STP behaves quite similarly to RIP, a simple distance vector routing protocol - STP tries to find the shortest path from each switch to a single particular destination - the root bridge. RIP sends updates every 30 seconds. STP sends updates, or BPDUs, every 2 seconds. The fields in BPDU can be likened to:

Root Bridge ID - the destination
Root Path Cost - the metric
Sending Bridge ID - the next hop
Sending Port ID - the next hop interface

Just as RIP runs forever, so does STP. By saying that STP converged we simply mean that the repeated runs of the STA triggered by a BPDU arrival always yield the same result. The STP never stops running. Every time a BPDU arrives, the switch needs to make comparisons of this BPDU to other stored BPDUs to see if there is any relevant updated information available, therefore we continuously need to determine whether the just received BPDU is inferior, identical or superior.

Best regards,

Peter

View solution in original post

Peter Paluch · ‎07-01-2013

Hi Chris,

These are some great questions you are asking.

First of all, I assume you are familiar with this document:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a0080094954.shtml

This document very nicely explains how the individual timers in STP are calculated, based on a few assumptions about the network diameter and the speed of processes on bridges/switches, the default values being very conservative. Note how the document shows that once you make an assumption that the Hello interval is 2 seconds and the network diameter is 7 then the MaxAge can really be computed to be equal to 20 seconds.

That is to say that a frame traversing the network end to end should not  exceed 7 hops. If this is the case, then why have a max age of 20?

Because, as the document explains, for a network having the diameter of 7, it may take up to 14 seconds between two successive BPDUs as they are originated on one end of the network, possibly lost, and travel the whole diameter to the other end, plus the time reserve we need to have to not age out these BPDUs prematurely (as they will be aged out after MaxAge-MessageAge seconds in STP) which is 6, yielding a total of 20 seconds.

Or in the case of MST a max hop count of 20?

The 20 here is just a legacy value retaken from old STP. Please note that neither RSTP nor MST age out BPDUs after the MaxAge-MessageAge seconds. BPDUs in RSTP/MST age out after three consecutively lost BPDUs (3xHello). The MessageAge in RSTP is used for sanity checks - if the incoming BPDU has its MessageAge equal to or higher than the MaxAge then the BPDU is discarded right away.

MST does it similarly but in addition to MessageAge in the IST part of the BPDU (configured using spanning-tree mst max-age) that gets incremented, there is also a "CIST Remaining Hops" field in the MST Extension part of the BPDU which is set to 20 (configured by spanning-tree mst max-hops) that gets decremented, and if it drops to 0, the BPDU is also discarded.

So in RSTP and MSTP, the MaxAge is merely a sanity limit on the diameter of the switched network. It is not really a timer RSTP/MSTP would be using.

Please feel welcome to ask further!

Best regards,

Peter

Craddockc · ‎07-02-2013

Peter,

Thank you so much for the link and the explanations! They really helped me! I do have a question regarding the BPDU's themselves. The documents states:

"When a new configuration BPDU is received that is equal to or better than the recorded information on the port, all the BPDU information is stored. The age timer begins to run. The age timer starts at the message age that is received in that configuration BPDU. If this age timer reaches max age before another BPDU is received that refreshes the timer, the information is aged out for that port."

What does it mean that if the BPDU info is "equal to or better"? What makes one BPDU better than another? Is it the priority of the Root Bridge that sent it? What values in the BPDU cause the bridge to decide whether or not to save th einfo and start the age timer? Thanks.

Chris.

Peter Paluch · ‎07-02-2013

Hello Chris,

It has been a pleasure. Thank you!

Best regards,

Peter

Craddockc · ‎07-02-2013

Peter,

Sorry to hammer you again with another question. I edited my first reply to you. I did have another question for you. The link documented stated the following:

"When a new configuration BPDU is received that is equal to or better than the recorded information on the port, all the BPDU information is stored. The age timer begins to run. The age timer starts at the message age that is received in that configuration BPDU. If this age timer reaches max age before another BPDU is received that refreshes the timer, the information is aged out for that port."

What does it mean that if the BPDU info is "equal to or better"? What makes one BPDU better than another? Is it the priority of the Root Bridge that sent it? What values in the BPDU cause the bridge to decide whether or not to save the info and start or restart the age timer? Thanks.

Chris.

Peter Paluch · ‎07-02-2013

Hello Chris,

STP builds on the capability of comparing any two BPDUs to see which one is better, or superior, to the other which is considered worse, or inferior.

Two BPDUs are compared to each other by comparing the following fields from the BPDUs in the indicated succession:

Root Bridge ID (consisting of priority, VLAN, and MAC address)
Root Path Cost
Sending Bridge ID (consisting of priority, VLAN, and MAC address)
Sending Port ID (consisting of priority and port index)

Lower value wins.

You always start comparing the two BPDUs by comparing the Root Bridge ID in both BPDUs. If any of these BPDUs contains a lower Root Bridge ID, that BPDU is considered superior and the comparison stops.

If both BPDUs contain the same RBID, you proceed to compare the Root Path Cost. Again, if one of the BPDUs has a lower RPC than the other, it will be considered superior and the comparison stops.

If both BPDUs contain the same RPC, you proceed to compare the Sending Bridge ID. Again, either one of the BPDUs has the SBID value lower (in which case it is the superior BPDU), or in case the SBID is identical in both BPDUs, you proceed to compare the Sending Port ID, and again, the BPDU having the lower SPID value is considered superior.

In short, you compare two BPDUs by comparing the fields mentioned above, looking for the first inequality. The BPDU containing a lower value in the compared field is better, or superior.

Does this make any sense?

Best regards,

Peter

Craddockc · ‎07-02-2013

Peter,

This makes perfect sense. I guess I always just assumed that as soon as soon as a RB was elected that the comparison of BPDU's stopped, but it makes sense that it would keep comparing each BPDU it receives with the one it already has stored for that interface. Otherwise, how else would it know if it received a superior or inferior BPDU? All of this is coming into focus now. Thanks again! You have been a tremendous help!

Chris.

Peter Paluch · ‎07-02-2013

Hello Chris,

Yes, the comparison of BPDUs never stops. In essence, STP behaves quite similarly to RIP, a simple distance vector routing protocol - STP tries to find the shortest path from each switch to a single particular destination - the root bridge. RIP sends updates every 30 seconds. STP sends updates, or BPDUs, every 2 seconds. The fields in BPDU can be likened to:

Root Bridge ID - the destination
Root Path Cost - the metric
Sending Bridge ID - the next hop
Sending Port ID - the next hop interface

Just as RIP runs forever, so does STP. By saying that STP converged we simply mean that the repeated runs of the STA triggered by a BPDU arrival always yield the same result. The STP never stops running. Every time a BPDU arrives, the switch needs to make comparisons of this BPDU to other stored BPDUs to see if there is any relevant updated information available, therefore we continuously need to determine whether the just received BPDU is inferior, identical or superior.

Best regards,

Peter

Craddockc · ‎07-03-2013

Peter,

WOW! What a great analogy! I would have never thought of STP in terms of RIP like that. But now that you say so it makes complete sense! Thank you so much for the inspirational and well detailed responses! I am so grateful for you taking the time to explain this to me. I always felt like I had a good grasp of STP but this just makes it so much better. Thanks again!

Chris.