cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

RSTP Issue

SOLVED
Here to help

RSTP Issue

Hello everyone,

 

First time poster.  Anyways, I'm having some RSTP issues.  As you can see below in my diagram, we have 3 buildings that have L3 switches (Buildings A, B & C) which control our routing.  The 10.10.1.0/30 & 10.10.2.0/30 networks are intermediary networks between the layer 3 switches at each location via fiber.  All traffic leaves thru building A.  Buildings A, B & C each have two L3 aggregation switches with redundant fiber links between them to both switches.  One major issue I'm having is that the RSTP root for all the interconnected buildings is Aggregation Sw1 at building A.  This is causing issues since anytime we have to reboot Aggregation 1 at building A the entire network starts reconverging.  Also, when we connect the redundant fiber links between building A and building B (or building C) STP blocks the crosslink between the two aggregation switches at building B instead of the redundant fiber.  All L3 switches are MS420s and all switch links via fiber are currently set to trunk.  I'm thinking the best solution is to have a seperate RSTP instances running at Building A, B & C.  I'm just not sure how to separate the instances since Meraki can't do routed ports.  Any help would be much appreciated!  Thanks guys!!

 

 

Meraki Diagram 1.jpg

 

1 ACCEPTED SOLUTION

Accepted Solutions
Kind of a big deal

Re: RSTP Issue

I'm going to assume that all the switches are Cisco Meraki.  As Meraki switches don't have routed ports all ports are layer 2, and will participate in layer 2.

 

The links between building B and A should be put into a port channel.

The links between building C and A should be put into a port channel.

 

This will make the entire design loop free.

 

Building A should be the root of the spanning tree.  You should make building B and C the secondary [equal cost] roots.  This is so that if switch A is rebooted the remaining portions of the network do not see any topology change.

 

Rebooting the switch in building A should not cause any convergence issues.  Convergence should be near instant in a network of this size - like in the order of sub 10ms.  I assume you have left RSTP enabled.

 

If you are not running 10.x firmware upgrade immediately.  It has massive spanning tree improvements.

8 REPLIES 8
Kind of a big deal

Re: RSTP Issue

You have L3 switches, aren't you better off using an L3 design so you don't need STP?

Here to help

Re: RSTP Issue

Can you illustrate or explain?  We already have static routes between each building that do the routing and since Meraki doesn't allow for routed ports how can we do purely L3?

Head in the Cloud

Re: RSTP Issue

How is Building A the RSTP root bridge for the entire network? Remember RSTP operates at layer 2. Looking at your design you have Layer 3 throughout your network between the buildings.

 

If the Layer 2 gateway for Building D + E is Building B This is the root bridge for those layer 2 networks. E + F Layer 2 Gateway is Building C. This is the root bridge for those layer 2 networks.

 

Meraki switches have the ability to act as a layer 3 and can operate SVI's which can be used for routing/layer 3 purposes. 

Eliot F | Simplifying IT with Cloud Solutions
Found this helpful? Give me some Kudos! (click on the little up-arrow below)
Here to help

Re: RSTP Issue

I agree it's a strange situation but building A is the rstp root for the entire network.  I believe it may have something to do with the fact that the links between building a and b and building a and c are trunk links that are allowing a few vlans across which is extending the layer 2 broadcast domain.  I'm wondering if setting the links to access ports would fix this and allow the separation of rstp instances?

Kind of a big deal

Re: RSTP Issue

I'm going to assume that all the switches are Cisco Meraki.  As Meraki switches don't have routed ports all ports are layer 2, and will participate in layer 2.

 

The links between building B and A should be put into a port channel.

The links between building C and A should be put into a port channel.

 

This will make the entire design loop free.

 

Building A should be the root of the spanning tree.  You should make building B and C the secondary [equal cost] roots.  This is so that if switch A is rebooted the remaining portions of the network do not see any topology change.

 

Rebooting the switch in building A should not cause any convergence issues.  Convergence should be near instant in a network of this size - like in the order of sub 10ms.  I assume you have left RSTP enabled.

 

If you are not running 10.x firmware upgrade immediately.  It has massive spanning tree improvements.

Meraki Employee

Re: RSTP Issue

@PhilipDAth is on the right path here - you'll just need to make sure that, if they aren't already, each MS420 pair, in each building is a physical stack: https://documentation.meraki.com/MS/Stacking/Switch_Stacks#Understanding_Flexible_Stacking
This allows the port channels (LAGs) to be created
Here to help

Re: RSTP Issue

Thanks for your help!  I haven't had a chance to implement this yet but I feel confident it will work.  I didn't know about the flexible stacking feature and actually I was told by several Meraki techs that stacking wasn't available on the 420 switches but I can see that it is with flexible stacking!  Thank you very much for the help!

Here to help

Re: RSTP Issue

Awesome suggestions! Will implement this very soon and am confident it will work well!!
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.