RPVST Root Bridge Change

[mfarrenkopf]

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):

• Old-dist:  not root, start priority 32768, end priority 32768
• New-dist:  root, start priority 16384, end priority 24576
• Access-1:  Po20 root port at start, went to blk/STP dispute, then recovered after 15 seconds.

I ran a similar test on Old-dist and this didn't occur:

• Old-dist:  root, start priority 4096, end priority 8192
• New-dist:  not root, start priority 16384, end priority 16384
• Access-1:  Po2 root port at start, Po2 root port at end, did not see STP dispute; based on ping tests, lost about 2 seconds of traffic

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

[Jon Marshall]

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

[mfarrenkopf]

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

[Jon Marshall]

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

[mfarrenkopf]

Hi Jon,

I repeated my tests and got similar results as before.  A couple of additional notes:

• When I set the 7K to be the root and set Old-dist to be priority 32768, I noticed that the Old-dist side of Po2 went into Alt/Blk, telling me it thought Po2 was a root port and Access-1 was designated.  That was different from my first set of tests.  I need to check that again.
• More importantly perhaps, and unique to the Nexus environment, is that the vPC peer link can be a second root port.  Access-1 and New-dist and Old-dist are each pairs of Nexus switches working together that look like one to the rest of the network.  However, they're not one, and that peer link does pass BPDUs and participate in the topology.  I saw another STP dispute on the Old-dist side of Po2.  So . . . perhaps the peer link is passing BPDUs and Access-1 or Old-dist1 sees a different BPDU coming down the pipe and it knows they don't agree.  And it probably explains why I don't see something similar in my 3750 lab setup.

I appreciate your input on this and labbing some of this out!!

Take care,

Matt

[Jon Marshall]

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