02-18-2016 12:32 PM - edited 03-08-2019 04:37 AM
Greetings,
I'm in a project to change the distribution layer in our data center. Most of the spanning tree roots are on the old distribution switches. I need to move them to the new switches. We didn't have a standardized priority setup before this, so our root priorities are somewhat "all over the place." Before, we needed to ensure the distribution layer was the root. So priority 0, 8192, 24576 . . . something better than 32768 was all we worried about. But some of the roots are on the new distribution layer because the VLANs were created after the new switches were production.
So I'm establishing new L2 links to the new distribution layer. I also want to establish a standard root priority of 4096.
See attached diagram. The dashed line is the new L2 link.
I ran a whole slew of tests. One in particular (illustrated in attachment):
I ran a similar test on Old-dist and this didn't occur:
What this boils down to: I'm not clear on expected behavior when the existing root gets its priority changed to a worse priority but still good enough to retain the root role. In my mind, the downstream switches believe it to be a brand new root since the bridge ID has changed. I have nothing else with a priority high enough to be root. (Access-2 is illustrated but no changes were made to it during these tests.)
I need to present the results to our change board, so I need to be able to explain the results I'm seeing. I'm not sure what to say about the difference between the two tests. And if the explanation is as simple as "here, read this," I'm happy to do it. I've read through the 802.1 documentation and I've read Cisco's Understanding RSTP document.
Thanks,
Matt
02-18-2016 03:40 PM
Matt
The short answer is, as far as I am aware, you should not be seeing the results you are.
The STP dispute mechanism is used when both ports at either end of a link believe they are designated ports which obviously shouldn't happen as this can lead to a loop.
It usually caused when the access switch, in your example, stops receiving BPDUs from the distribution switch and so moves it's port to designated. The distribution switch then receives BPDUs from the access switch but they are inferior to it's own BPDUs so it knows the access switch is not seeing the BPDUs it is sending and so blocks the port.
This could happen with a unidirectional link or a misconfigured etherchannel between the two switches but usually it is the root switch that blocks it's port not the access switch.
The fact that it recovers and that it is the access switch that is blocking the port suggests something else is going on.
Difficult to say what without seeing configurations of old and new switches and also some outputs while the port is in dispute but as I say this shouldn't happen as far as I know as long as the access switch never receives a BPDU from anywhere else with a better priority.
Edit - what platforms are the distribution switches ?
Jon
02-19-2016 08:46 AM
Hi Jon,
The only reason I could see getting the STP dispute was if there's information I'm missing (and I believe there is) about how RSTP handles a priority change where the same bridge retains the root state. If you can enlighten me on that, I'd appreciate it. Other than that, I thought the same thing -- I shouldn't be seeing STP dispute in this scenario.
All switches are Nexus line using a vPC configuration. Access-1 and Old-dist are 5548UPs. New-dist is a pair of 7010s. Access-2 is a pair of 6001s. All switches are interconnected as vPC pairs to each other; we are not using FabricPath.
I have no reason to believe my links aren't patent. Once STP converges, I can pass traffic bidirectionally with no issue. vPC has no complaints.
I'll be repeating the tests later today. If the problem recurs and I can grab the output of the STP dispute, I'll post it here.
Thanks,
Matt
02-19-2016 09:42 AM
Matt
Ignore what I said before, I don't think it is right.
If the access switch receives the update BPDU on it's root port first then it knows it has a better BPDU on it's alternate blocked port.
In which case as far as I can see that is a topology change from the access switches point of view.
Let me run a test (not on Nexus unfortunately) and see if I can emulate the problem.
Jon
02-22-2016 12:36 PM
Hi Jon,
I repeated my tests and got similar results as before. A couple of additional notes:
I appreciate your input on this and labbing some of this out!!
Take care,
Matt
02-19-2016 05:40 PM
Matt
Did some testing and when you increase the priority of the root switch it does indeed cause a topology change.
What I can see from the debugs is that when the access switch receives the updated priority from the new distribution switch it unblocks it's alternate port via the old distribution switch making it the root port and then sends a proposal to the new distribution switch.
In that proposal the access switch is saying that it's port connecting to the new distribution switch is designated and as that BPDU is received on a designated port I think that is where the dispute may be coming from.
In the lab I ran the root switch rejects the proposal and the access switch then reselects the port to the new distribution switch as the root port.
The switches I have don't implement the STP dispute mechanism so the above is just best guess (and not necessarily right) from what I can see from the debugging.
Hope that is some help.
Jon
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide