Spanning Tree and VSS recommended best practice

[axeleratorcisco]

I am about to build a VSS core, with stacked distribution switches below them (all L3 interfaces are terminated on the VSS core).

Theoretically you could get away with only STP at the access layer right?

Since all Dist switches will have one logical uplink to one logical core.

Is it still recommended to activate STP on both Dist/Core switches?

Do you just dump all VLANs in one instance? (with MSTP)

If the old core is running CSTP and you are migrating to MSTP on the VSS, is that VSS backwards compatible with old CSTP access layer devices attached?

[Mark Malone]

Your VSS should be the root for all vlans , its best practice campus design , I don't use MSTP I'm using RPVST as below but it should be root for all whether MSTP or PVST

spanning-tree mode rapid-pvst
spanning-tree portfast edge bpduguard default
spanning-tree extend system-id
spanning-tree vlan 1-331,1222,2991-2994 priority 4096
port-channel load-balance src-dst-port

Then I just leave the dist and access as standard works well

spanning-tree mode rapid-pvst
spanning-tree extend system-id

Read this doc for best practice STP in VSS

https://www.cisco.com/c/en/us/td/docs/solutions/Enterprise/Campus/VSS30dg/campusVSS_DG/VSS-dg_ch3.html#wp1079779

Root Switch and Root Guard Protection

The root of the STP should always be the VSS. Use a statically-defined, hard-coded value for the spanning tree root so that no other switches in the network can claim the root for a given spanning tree domain. Use either Root Guard on a link of VSS-facing access-layer switch or enable it at access-layer switch user port (although the later does not prevent someone from replacing access-layer switch with another switch that can take over as root). The root change might not affect forwarding in non-looped designs (root selection matter only when alternate path (loop) is presented to STP); however, the loss of BPDU or inconstancies generated by a non-compliant switch becoming root could lead to instability in the network.

[axeleratorcisco]

Thanks!

I am running CSTP on the current cores.

I would like to connect the new cores to the old cores via a trunk. Then at some point do a move of the SVIs from old cores to new cores.

Can I already make the VSS the spanning tree root of the entire network, with all vlans in instance 1, and then change the old cores to function as a simple L2 pass through?

This new VSS core will then have only two links to the old cores, so some form of spanning-tree will be needed.

But this should give the opportunity to building wise connect the new stacked-switches to the new core, which are already pre enabled with MSTP with all VLANs in instance 1.

Or would the new VSS core have no backwards compatibility with the old CSTP cores (and underlying devices)?

[chrisgray1]

Hi,

I've done a similar move before at a big live site which went without any issues. I connected the new VSS core, we were using RPVST not MSTP, to the old core over a vlan trunk.

I bought up the VSS core with the SVIs shutdown. So they did not form routing adjacencies for the same subnets right away and also configured with lower priority HSRP. Then added the new VSS core to the old core via a vlan trunk.

Once online connected each of access layer switch stacks to the VSS core via etherchannel.

brought up the SVIs first formed adjacency on the routing vlan / interfaces.

Then the other SVIs for each of the internal vlans.

Raised the HSRP priority on the new VSS core SVIs so that they became the new gateway.

Disconnected the old core switch interfaces.

That is how I did it. Then the checked that the old switch was passing no traffic on the interfaces before removing it.

Are you really using CST, or do you mean the older default value which is PVST+, not RPVST?

Between MSTP and PVST there is a region boundary. So it means essentially that the MST switches will send the BPDUs for each vlan outside the MST to the PVST switches. In that case I believe that it is transparent. The new core will hear about the root from the old core switch.

[axeleratorcisco]

It's basically HP instead of Cisco (with VSF instead of VSS but the idea is the same).

The current cores are configured with just the spanning-tree command. If you want to enable MSTP you have to use spanning-tree instance 1 VLAN x-y command.

I have some access layer switches running MSTP already, and they can operate perfectly with the current CSTP core and other switches.

The idea is to not only migrate the old cores, but also configure all access layer switches in MSTP mode.

And instead of a direct access layer, I have multiple buildings with distribution switches running CSTP. So I would want to connect the current Access Layer to the new Distribution switches, but there are 6 buildings, so it's impossible to do this for all buildings in one go.

Therefore I want to keep the old Cores in place as a layer 2 pass through, and connect each building's access layer to the new Distribution switches. Furthermore for each building, each access layer switch needs to have MSTP enabled. My worry is: can I move the SVIs from old Core to New, and at that same time make the new VSS Core MSTP enabled for all VLANs?

Or am I risking that all network devices can't interact with this new VSS core?

If I understood correctly, when enabling MSTP on a switch, it can perfectly cooperate with CSTP switches. In this case only the 2 old Cores are connected. Every other old distribution switch is still connected to the old Cores. The VSS Core would be sitting in its own region and see itself as the root for that region since no other MSTP switches are directly connected to it. But the CST should take care that all other network devices can interoperate with this switch right?

[chrisgray1]

hmmm. The MST core will send compatible BPDUs to the non MST switches. It must be root for all vlans, you cannot have the old core as a root for some of them otherwise its inconsistent.

But I've never tried this compatibility scenario with MST to be honest.