2

I am preparing for migration of this rather simple network layout from RST to MST:

Network diagram

From what I have read so far, it looks like the best approach is to avoid interoperability issues and simply rollout the MST to all four switches, make this all a single region and this is the path I am taking right now. My understanding is to also try and keep the number of instances in a single region to a minimum - since each instance has an independetly computed spanning tree, this saves switch CPU resources.

My instance layout would be like this:

  • IST -> VLAN 1
  • MSTI1 -> VLANs {T1 union T3 union T4} except VLAN 200
  • MSTI2 -> VLANs 70-90 (trunk T2)
  • MSTI3 -> VLAN 200 (trunk T5)
  • MSTI4 -> all remaining VLANs not participanting in trunk links (not shown here for brevity)

Failover is not a requirement at this moment.

Questions:

  • do I need to make MST instances configuration identical across all switches of the region? In particular, if a switch doesn't have a VLAN defined right now, would I need to define it despite the switch not routing packets tagged with this VLAN? My understanding is that I would need to do so in order to exactly mirror the instance config across all switches
  • consider T1 and T2 trunks on the diagram. How would I choose an MST instance root in this case? In particular, would it be better to keep roots of both MSTI1 and MSTI2 on "Core" switch or is it better to announce N3024 as the instance root of MSTI2? How does one decide this in general?
  • same question above for the T4 and T5 trunks on the bottom of the diagram
Improve this question
2
  • There's no need for IST4. All VLANs are in CIST unless and until assigned to a different instance.
    – Ricky
    Mar 25 at 13:26
  • I thought best practice is to maintain only VLAN 1 (management traffic) on IST?
    – quantum
    Mar 26 at 8:09

2 Answers 2

Reset to default
2

Yes, MSTIs need to be identical across a region in order to work. The configs are hashed and if the hashes don't match the instances won't work.

When the MSTIs more or less cover the same area - as in your case - you can leave the root (and failover root) as is and control the spanning tree using port priorities alone. Different root bridges make sense when you've got a redundant core where each core switch becomes one of the roots.

I have to note that the point of STP is to provide failover connectivity. If you don't need that you could also filter BPDUs on the trunk links and be done without xSTP.

For STP to make sense you should add the remaining VLANs to the parallel trunks and create additional physical links between non-adjacent switches. (It looks like you're chaining switches which isn't a good design, but that may be due to just showing us a representative part of your network.)

Improve this answer
5
  • Do you see any issues with the instance design as above? Is anything coming off as suspicious? I should note - the only reason I am considering the MST is basically to load-balance VLAN traffic over multiple trunk links. I am relying on the STP to simplify maintenance and reduce manual configuration with manual disabling the spanning tree on select ports, being careful around not making loops etc. I tried running the network without spanning tree but the pings were apalling. I saw pings going as high as 30 ms which dropped almost immediately to 1-2 ms after RST was enabled and converged.
    – quantum
    Mar 25 at 8:33
  • The network in your diagram should work fine without STP - perhaps you should diagnose where the problems came from. However, I'd use MSTP with multiple instances plus a more resilient base topology (tree instead of chain) to create a load-balanced and redundant network.
    – Zac67 ♦
    Mar 26 at 7:48
  • Unfortunately, I am currently constrained by the physical link availabilty. The single fibre link that serves T3 is the only link between two separate physical locations (buildings). At the moment, it just isn't feasible going into the expense of routing extra links to support full redundancy.
    – quantum
    Mar 26 at 8:08
  • In such a situation I've used single-strand 10GBASE-BR (aka "bidi", "BX"), so your fiber pair could run two individual links. ;-)
    – Zac67 ♦
    Mar 26 at 9:01
  • I have completely forgotten about this!! :facepalm: What an excellent suggestion - that is a great idea, I can't believe I didn't think of BiDi transceivers. Let me look into this - thank you!
    – quantum
    Mar 26 at 15:56
2

There are some things to watch out for here:

  1. I would suggest to manually assign root priorities for the instances you're using, including the IST
  2. Be aware that any VLAN you create after making the above assignment of VLANs to MST instances will automatically land in IST (this alone isn't a problem yet, but it will become one with the following)
  3. Changing the assignment of a VLAN to an instance will bring down your switched network for the time the switches need to re-learn the new topology. And what Zac mentioned comes into play here too: the configuration will need to be identical on all devices within one region, otherwise you would split up the regions, and then a different election process comes into play. So changing the VLAN to instance mapping on one device (especially with mapping VLANs to different ports) will bring you all kinds of pain, unless you have an OOB way to manage those switches.

MST is nice on paper, but the downsides pile up when you actually trying to run it I'm afraid.

Improve this answer
2
  • Good points! Much of the operating pain can be taken away by carefully designing your management VLAN topology though, or using OOB with dedicated cabling as you've stated. Since the network design in question doesn't seem very sophisticated, the management VLAN approach might not work too well, granted.
    – Zac67 ♦
    Mar 26 at 7:41
  • Thank you - these are indeed useful points. I honestly can't see additional VLANs created in short and medium term as the VLAN layout is already quite segmented and prepared for future growth. As a further simplification, the T5 trunk is really a nice-to have - would it make things easier to manage if I simply rolled out MST for T1 and T2 trunks? That would make only those two switches a region, whereas the other two switches would rely on RST. Would this make things any simpler to maintain? I have OOB access for those two switches.
    – quantum
    Mar 26 at 8:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.