1

We have inherited a ring topology with 12 switches configured with MSTP. Each switch is either 4 or 8 ports but in general most are 4 port with 2 fiber uplinks that form the ring.

We are getting a what appears to be a significant number of topology changes in the stats:

stats from switches show a high number of topology changes: 3185

I`ve looked at a few posts that suggest there is a maximum number of switches/bridges in a ring. Although the posts do relate to RSTP not MSTP.

RSTP recovery time with Ethernet ring

I`m trying to find concrete primary proof that this is the case and to identify the maximum switches in a ring. It may that the maximum is also influenced by MSTP settings of which I have limited knowledge at present.

Kind Regards

Aidan

  • what is your problem? Your explanation make confusion – infra Aug 15 at 8:29
  • Sorry its running MSTP. So the question: Is there a limit to how many MSTP switches you can have in a ring topology before problems occur? – Aidan Venn Aug 15 at 8:48
  • @user56700 MSTP is downward compatible to RSTP (and even classic STP) for the CIST (see 802.1D Clause 17). – Zac67 Aug 15 at 11:37
  • 2
    @AidanVenn With MSTP default parameters, the tree depth must not exceed 7 bridges. – Zac67 Aug 15 at 11:49
  • 2
    A ring topology for ethernet switches just is not the way to do it. Remember that every frame to a device not directly connected to the switch will be sent toward to root bridge, and rings (witch are broken by STP into a single line of switches) do not work well that way. The reason it is called a root bridge is that the topology should be a tree topology, not a ring (trees have roots, rings do not). – Ron Maupin Aug 15 at 13:26
3

stats from switches show a high number of topology changes: 3185

While large STP rings are not always a good design, I doubt that the high number of Topology Changes you observe has to do with ring size.

I suggest reviewing the ports where edge devices are connected. These should be configured as spanning-tree port type edge [trunk] or spanning-tree portfast [trunk] (depending on platform and vendor, the syntax may vary).

If STP edge ports are not configured as such, each time one of them transitions from LRN to FWD state, a STP Topology Change Notification (TCN) will be flooded across the given spanning-tree(s). That will happen if the given attached server or PC boots.

That might readily explain the high number of (apparent) TCs the switches report.

  • Thanks Marc. On site in the next few days and will have a look. – Aidan Venn Aug 15 at 8:52
2

In addition to Marc's answer:

  • Make sure you've defined a root bridge (lowest priority) and don't just leave that to chance. If some edge switch is randomly elected root, every change triggers at least one TCN.
  • You should also define a failover root bridge (designated, second lowest priority) to still guarantee a defined tree in case the root bridge is offline.
  • With a switch off the ring elected as root, the total depth may exceed MSTP's design limit of seven bridges in depth (=radius from the root's POV), so the tree never really converges. Trees of that depth require tweaked STP parameters.
  • Better yet, those tree depths and rings in general should be avoided - consider rewiring to a tree topology (=one or two core switches =STP root and designated) plus redundant links where required.
  • thank you (NOT!) for planting that earworm (as in: Peter Maffay's version of "Über sieben Brücken" de.wikipedia.org/wiki/…) in my head. Day completely, utterly ruined! SCNR ;-) – Marc 'netztier' Luethi Aug 15 at 11:58
  • I'm not responsible for Maffay's lapses! Maybe you should supplant that with The Eagles' Seven Bridges Road... – Zac67 Aug 15 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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