RSTP Synchronization

bermovick

I've been trying to work my way through STP. It's been slow going since it seems to be mostly theory. I think I've finished STP and almost finished RSTP - the only thing I'm kindof getting stuck on is part of the synchronization process.

I've got most of it - how the root sends the proposal bpdu & the receiving switch receives it, blocks the other (nonedge) ports, sends agreement back and both ports immediately go forwarding (as designated & root ports), then the process repeating itself with the 'receiving' switch becoming the sending switch for the next 'pulse' of synchronization.

Where I'm getting stuck is when an inferior BPDU is received (or sent since we can see the big picture and know ahead of time where it will be). None of the examples I've read or looked up online go into the inevitable conclusion where a switch sends what will be an inferior BPDU for the receiving switch.

I eventually just threw together a 3-switch lab and brought up debugging (spanning-tree events seems most useful). I configured the priority on 2 of the switches to be certain which would be primary and secondary roots, then started wiring them together. I expected to see when I put the 3rd link up (between highest and lowest priority) for the highest priority to get a new superior BPDU over the new link (which it did), and once it synced to send a BPDU over it's other link that would be inferior - but that's not what happened.

F0/2 is to the root and is the new link, F0/1 is to secondary root (and was best path before hooking up 0/2)

Jan 12 06:51:46: RSTP(1): initializing port Fa0/2
Jan 12 06:51:46: RSTP(1): Fa0/2 is now designated
Jan 12 06:51:46: RSTP(1): transmitting a proposal on Fa0/2
Jan 12 06:51:46: RSTP(1): updt roles, superior bpdu on Fa0/2 (synced=0)
Jan 12 06:51:46: RSTP(1): Fa0/2 is now root port
Jan 12 06:51:46: RSTP(1): Fa0/1 blocked by re-root
Jan 12 06:51:46: RSTP(1): Fa0/1 not in sync
Jan 12 06:51:46: RSTP(1): Fa0/1 is now alternate
Jan 12 06:51:46: RSTP(1): synced Fa0/2
Jan 12 06:51:46: RSTP(1): synced Fa0/2
Jan 12 06:51:46: RSTP(1): transmitting an agreement on Fa0/2 as a response to a proposal

I'm not quite sure why it didn't send a BPDU out 0/1 to see if the switch on the other end would use it as a better path. I was expecting that, so I could see what happened when it was rejected. Does anyone know how this switch was able to determine it's neighbor would NOT have considered it's BPDU as better?

bermovick

In case I explained poorly (I feel I did!), I found a site that did exactly what I did. It's Figure 10-11 here.
Introducing Rapid Spanning Tree Protocol :: Chapter 10. Implementing and Tuning Spanning Tree :: Lan switching fundamentals :: Networking :: eTutorials.org

I don't see why Switch3 didn't send a BPDU to Switch2. Yes, switch 2 would have rejected it but I don't see how Switch3 apparently knew that (or chose not to try)

mattau

Id love to know how this works also, man I have been racking my brain over this! sure its easy to understand the general gist of how the RSTP sync works but when it comes to looking at practical scenarios about reconvergence nothing is all that clear. Why doesnt sw3 send the bpdu to sw2?my feeling is sw3 must just realise it has to be blocking because sw2 is the designated switch for that segment and still forwarding it BPDU's.I am guessing RSTP is just superfast and the switches are very intelligent and can work out who is the designated switch for the segment and sw3 knows that it must block the port immediately.anyone else have some ideas?

wave

I would also like to know the answer to this!

wave

I think that it doesn't send a BPDU out fa0/1 because that port was already determined to be a root port - and there has been no topology change on that link so the switch with the new link knows that it can't send a BPDU on that port. BPDUs are never sent through Root Ports unless there is a topology change

"As long as the root switch is elected the Root will send BPDUs to the downstream switches and there will be no BPDU sent from Downstream switches to the Root unless there is TCN." See: https://supportforums.cisco.com/thread/2077559

When fa0/2 comes up as the new Root Port the switch thinks "Okay I have a better RP so I'll block my old RP. I haven't received a topology change proposal on fa0/1 and I know it was a RP so I better block it"

mattau

I am still confused. I dont get why sw3 knows to straight away put its port going to sw2 into the alternate blocking state. sure this is correct when you do it on paper but i cant see how it comes to this conclusion in real time so quick.

just reading over a few points in this white paper, under the Processing Superior BPDU Information section


Catalyst 2950 Desktop Switch Software Configuration Guide, 12.1(9)EA1 - Configuring RSTP and MSTP* [Cisco Catalyst 2950 Series Switches] - Cisco Systems

When that new link comes up between sw1 and sw3, sw3 receives the superior bpdu and does the proposal agreement with sw1 to get the link up. Hence it should block the port going to sw2 before it can send the agreement to sw1. But then in the white paper it also says if a switch looses its root port it immediately puts it into the blocking state..

?

wave

mattau wrote: »

I am still confused. I dont get why sw3 knows to straight away put its port going to sw2 into the alternate blocking state. sure this is correct when you do it on paper but i cant see how it comes to this conclusion in real time so quick.

As soon as it sees the better BPDU (there's the lower cost to reach the root), BOOM, it blocks the current Root port to avoid the a loop.

From the whitepaper as you point out "Root ports—If the RSTP selects a new root port, it blocks the old root port and immediately transitions the new root port to the forwarding state. "

When SW3 receives that better BPDU it has the TC bit set - it's a proposal BPDU. SW3 knows it's going to respond with acceptance so it takes precaution by blocking the old Root Port and then saying "Yep, we're all on SW1"

mattau

thanks wave.

so I get that it has to block the port to sw2 to stop the loop but is this still part of the re sync process?

It will show up on sw3 as something like

Fa0/2 blocked by re-root

but how does fa0/2 know to be alternate blocking? is it because sw2 is still sending it bdpu's and sw3 figures out thats all it can be ? blocking.

wave

mattau I apologize, I think I've given you a bum steer here! I thought I had grasped this but it appears I was a little off. I just went back and re-read the RSTP sync section of the SWITCH FLG, please see the attached image from page 133.

In this example the original Root Port on Switch A would be the one pointing to Switch C. The text says that Switch A *will* send BPDUs on that Root Port, containing the information for the new Root Switch (which would have a lower cost).

(On page 134 under point 3. it states "While the [TC While] timer is active, the bridge sends BPDUs even on the root port)

It appears that:

1. Firstly the new port to the new Root is blocked and is in a listening state. Presumably the TC While timer starts here
2. While the new ports are blocking Switch A sends the better BPDU to downstream switches which contains a better path to the new Root
3. Switch A blocks it's Designated Ports and I'm guessing the old Root Port is blocked here.
4. The switches that receive the BPDUs with the TC bit set send this BPDU out their Designated Ports.
5. When Switch D (which was part of the original root-path) receives this BPDU (on port P1 in the picture) it blocks P1 and it will make that an Alternate port because it's still a path to the Root Switch but it's not as good as it's current path to the Root.

Happy to continue the discussion.

wave

As to why this process doesn't show in the debug....that's a very good question!!!

mattau

thats ok I have been labbing for a few hours tonight and set up some span sessions with wireshark


I shall report my findings tomorrow : )

But as a side note, looking inside the bpdu is pretty good. You can see how the ports do the proposal and agreement handshake and when they move into forwarding. I think it does clear up abit. Also I think the key to all of this is that the proposal messages are BPDU's anyway, which means they carry key information about changes in the topology and a switch can know if a port needs to go blocking ASAP even when they are in the resync stage. Like a port can receive a proposal BPDU then determine from that information the port must be blocking/alternate. I just need a little more time to re digest my findings.

but thanks for keeping this discussion alive : )

wave

Great, keen to hear what you find! Firing up Wireshark is going to be the most definitive, I really should use it more.

This is also good, similar to what's in the FLG but I got a little more out of it: http://www.cisco.com/en/US/tech/tk389/tk621/technologies_white_paper09186a0080094cfa.shtml#converge2

vinbuck

Here are two excellent docs on RSTP Synch

http://blog.ine.com/wp-content/uploads/2010/04/understanding-stp-rstp-convergence.pdf

Understanding Rapid Spanning Tree Protocol (802.1w)  [Spanning Tree Protocol] - Cisco Systems

The Cisco doc is what Boson references on their RSTP EX-SIM questions...

mattau

Thanks for the links. I read those many a times but still felt it still didnt explain what happens in various reconvergence scenarios. I dont expect to understand it fully.I believe the scenario posted originally in regards to why doesnt switch 3 send proposals down to sw2 as part of the resync process? I believe it has to do with sw2's port role being the designated port for the segment and NOT changing state when the new root port link on sw3 comes up, resulting in sw3 always having the same BPDU saved on its port facing sw2. Meaning it will always know that its not DP for that segment so it doesnt bother to propose to sw2 that it wants to be the DP.

Think this next situation is quite good though. This time instead of sw3 being blocking it will now be the DP for the segment. I was trying to visualize what the previously saved bpdu on each port was, then from there try to figure out what conditions change when a new link is added which could cause port roles to change.

:)Good topic though and had got me thinking in detail about it all.