Three switches in a triangle, or a row of switches where the last one runs back to the first: that is a ring. The intent is clear. If one cable breaks, every switch is still reachable the other way round. It only works if the spanning tree protocol opens exactly one path and keeps the rest shut, and if you decide which switch sits at the centre.
What the tool does
Under Bridge & ports there is a Spanning tree field with RSTP, STP, MSTP and off. RSTP is the default and lands in the script as /interface bridge add name=bridge protocol-mode=rstp. That happens on every device in the site, the router included.
If you draw the ring on the network board, the tool turns every cable between two devices into a trunk with all the site's VLANs tagged. For a ring that is exactly right: every path has to carry the same VLANs, or a broken cable takes down one VLAN instead of the network, which is far harder to find.
The tool notices the ring as well. In the checks across the site you get: the cable from one switch to the other makes a loop, RSTP then blocks one of the paths, it works but it does not add speed. That is not an error, it is confirmation that the board matches what you meant.
How RSTP picks a path
In three steps, in this order:
- A root bridge is elected. That is the switch with the lowest bridge ID, and that ID is the priority followed by the bridge's MAC address. Everyone starts at priority 0x8000, so without intervention the lowest MAC address wins.
- Every other switch picks its root port: the port with the lowest total cost towards the root. Cost follows speed, so a 10G path counts lighter than a 1G path.
- Per cable, one end declares itself the designated port. The port at the other end that is neither a root port nor a designated port goes into discarding: that is the blocking port.
An example with three switches on 10G, with sw-01 as the root:
| Device | Port | Goes to | Role | State |
|---|---|---|---|---|
| sw-01 (root) | sfp-sfpplus1 | sw-02 | designated | forwarding |
| sw-01 (root) | sfp-sfpplus2 | sw-03 | designated | forwarding |
| sw-02 | sfp-sfpplus1 | sw-01 | root port | forwarding |
| sw-02 | sfp-sfpplus2 | sw-03 | designated | forwarding |
| sw-03 | sfp-sfpplus1 | sw-01 | root port | forwarding |
| sw-03 | sfp-sfpplus2 | sw-02 | alternate | discarding |
The blocking port therefore sits on the cable furthest from the root, and which of the two ends blocks is decided by the lowest MAC address. Lose a cable and that port moves to forwarding within a second. That is the difference between RSTP and the old STP, which took thirty seconds.
Pin the root yourself
This is where the tool stops. There is no field for bridge priority and the script does not set one. Left alone, the root is the switch with the lowest MAC address, and that is as often the cheapest switch in a cupboard as it is the core switch everything converges on. The network works, but all traffic takes a detour and you cannot predict which port shuts during a failure.
So set it by hand, after pasting the script, on the switch you want at the centre:
/interface bridge set bridge priority=0x1000
And on the switch that should take over if the first one fails:
/interface bridge set bridge priority=0x2000
Write that on the handover sheet. It is two lines, and without those two lines your whole ring is a guess.
Mind the bridge MAC address
Because the bridge ID contains the MAC address, the outcome of the election changes when that address changes. RouterOS borrows the address of the first port in the bridge by default, so a port you later take out of the bridge can re-run the root election. That is why Bridge & ports has a MAC address of the bridge setting: pick Pin to the MAC of the first LAN port and the script fixes that address when you paste it. In a ring that is not a detail.
What to check after pasting
/interface bridge monitor bridgeon every switch. They all have to name the same root bridge, and it has to be the switch you gave priority 0x1000./interface bridge port printshows the role and state per port. You expect exactly one port in discarding across the whole ring.- Then unplug one cable from the ring and see whether everything stays reachable. A ring you never tested is not a ring, it is an assumption.
- Check that hardware offload is still on for the ring ports: that is the H flag in the same list.
A ring without RSTP
Set spanning tree to off and leave the ring in place, and this is what happens. One broadcast, an ARP request for instance, travels round the ring and arrives back at the switch that sent it. That switch sends it round again. There is no TTL at layer 2, so it does not stop. Within seconds every link is full, the MAC table on every switch is flapping because the same address arrives from two directions, and the CPU is pinned.
The unpleasant part is how you notice. Everything is unreachable at once: Winbox, the access point you are connected through, and the switch you would need to fix it. You solve it by physically unplugging a cable from the ring, not from your desk.
So leave spanning tree on, even when you are certain there is no loop. The price is a few BPDUs every two seconds. The price of the other choice is an evening in a cupboard.
About MSTP
MSTP is in the list and arrives in the script as protocol-mode=mstp, but the tool generates no MST region: no region name, no revision, no instances splitting VLANs across different trees. If you pick MSTP because you want a different path per VLAN, you have to add that configuration yourself. For a ring of three to ten switches carrying the same VLANs everywhere, RSTP does what you need.
Further reading: Bridge and ports, Cabling checks and Two offices, one design.