Mekari / Cisco - MSTP and RSTP Configuration Questions

[Qman]

I have been task with configuring STP for one of our customers and looking for some direction on how to configure the environment. The topology consist of Cisco 4506 devices on the end and Meraki MS425-32 and MS120-24 in the middle. I will be implementing MSTP and from the information I found doing my research, Meraki doesn't support

MST but is compatible and will see the traffic as one instance. From the information I have found to make the Meraki devices the root? Once the traffic passes through the Meraki devices the 4506 will re-elect a root bridge for the instance. So, if someone can inform on how to approach the configuration it will be greatly appreciated. My thoughts are below. Also, are there firmware concerns?

<cisco enterprise switch> -- <meraki switch> -- <cisco enterprise switch>

1. Configure the Cisco 4506 for MST only one instance for vlans

2. Configure the Mekari devices for RSTP

3. Make the Mekari devices the root\secondary for the vlans (several)

4. Set spanning-tree priority on one of the Cisco 4506 to elect preferred root bridge for MST instance

5. Include native or vlan 1 in the instance as the Mekari devices uses for processing ?

[PhilipDAth]

That sounds good to me.  If you have modified the spanning tree priority on the Meraki switches to makes them root you shouldn't need to mess around with priorities on the 4506.

[debo]

Would you use mst instance 0 or 1 . I understand it should be single instance but i see some suggest using 1 and others 0 

thanks

[Qman]

Hi,

I was going to use instance 1 can you tell me what would be the difference between the default 0 instance?

Thanks,

[PhilipDAth]

I would only use the defauly instance in this case.  So all you need to do is:

spanning-tree mode mst

[DCC]

hi, in summary, if i want to have a meraki switch as root bridge, with catalyst access switches, is it enough to enable mst mode (spanning-tree mode mst) on catalyst switches?

[debo]

@DCC yes just enable mst on ALL catalyst switches hanging off the meraki core. The keyword is ALL. hope it helps 

[GIdenJoe]

On the Cisco side it's always best practice to not only enable MST but also to put all Catalyst switches in the same region (by matching name, rev number and Instance to VLAN mapping).

Then you will have a clear boundary between the Meraki switches and the Catalyst switches.

Normally it is NOT best practice to use IST ( = MST 0) for VLAN mapping but with interconnecting to Meraki which only supports RSTP in case of classic MS switches you shouldn't have any potential PVST simulation error crap 😉

Be sure to allow VLAN 1 ( I know, strange) over the trunks so the interaction between MST and RSTP goes smoothly.

[Tore]

@PhilipDAth Do you know what will happen if both MST 0 and 1 is configured on the Catalyst (root)?

[GIdenJoe]

@Tore If you have an MST1 instance on the Catalyst then you will have a differente instance to VLAN mapping and have a different configuration digest.

This means your Meraki switch will no longer be in the same region and you'll have to reason how the MST region will interact with the Meraki MST region.

[Bruce]

@Tore the Meraki switches (since they run RSTP) will only interact with instance 0 of MSTP. Instance 0, the common and internal spanning tree (CIST), is used to carry the CST across the MSTP domain.

[Tore]

Thanks @Bruce So VLANs residing in MST 1 will not be visible to the Meraki RSTP switches at all, correct?

It might be safe to assume that MS390 switches wich are running MST are running MST default instance 0, correct?

Will it be problematic to have both MST 0 and MST 1 running on catalyst as long as the production VLANS reside in MST 0?

Thanks

[Bruce]

@Tore, MSTP (or RSTP) don't pass information about which VLANs are visible or not, it determines which paths to block to prevent Layer 2 loops in the network.

Within the MSTP region MSTP BPDUs are sent on the internal spanning tree (IST), this is instance 0. This is the only instance for which BPDUs are sent and received, they contain all the information for other instances within that BPDU. When the IST connects to another MSTP region, or a RSTP domain, then it is known as the common and internal spanning tree (CIST). 

At the boundary between MSTP and RSTP, the RSTP BPDU is used to interoperate into the common spanning tree (CST) of RSTP. The RSTP BPDU is fundamentally the MSTP BPDU but without the instance information (i.e. its just the BPDU for instance 0, the CIST). At this point you lose the two separate spanning tree instances and all VLAN spanning trees converge based on the RSTP BPDUs, you can still use all VLANs, they just don't have two separate trees. So if you have two paths between the MSTP region and the RSTP domain then one should end up blocking for all VLANs and one will end up forwarding for all VLANs; what this implies is that at the boundary port, if it is forwarding for the CIST then it is also forwarding for all other instances within the MSTP region.

I hope that makes sense - sorry lots of acronyms and can be confusing.

[GIdenJoe]

that's why STP is one of the hardest topics for any networking pro 🙂

[Bilbo007]

Hello @GIdenJoe, you mention below to ensure you allow VLAN 1 over the trunks. My native VLAN isn't VLAN 1 across my trunk links. Does it need to be for RSTP and MST to operate?

[GIdenJoe]

You can have any VLAN as native, but you surely need to allow that native VLAN across just to be sure your bpdu's come across nicely.

I believe the VLAN 1 issue is with how MSTP simulates PVST or RPVST on the link towards the switch running those protocols.  So tagged or untagged it's better to allow VLAN 1 over that trunk link even if you don't use VLAN 1.

[Bilbo007]

@GIdenJoe  thanks so much for your quick response.