RSTP Root bridge calculation

I’ve got 4 x CRS518-16XS-2XQ’s running the core of my switching network. Today I was looking at my bridges and found that what I thought should be the root bridge for RSTP is not the root bridge anymore.:
Status.PNG
Here’s my configuration:
Priorities.PNG
Is my understanding wrong? Given the priority on the switch on the left is 4000, which is lower than the one on the right, which is 5000, shouldn’t the switch on the left be the root bridge?

I’m running Router OS 7.15.3.

Edit: The switch on the left does have a higher numerical MAC address

Well, it’s just gotten even more ridiculous now:
Status-4.PNG
I removed an interface from the bridge that was root previously and now a switch with priority 7000 is the root. How does that work? Am I misunderstanding how root bridge elections work in RSTP?

Does your setup involve VLANs? VLANs can screw bridge priorities … if not configured properly.

I do have VLANs.
Do you have any documentation on how I should be setting priorities up with that in mind?

I have in the back of may mind (but can’t find a reference to it) that ultimate bridge priority gets defined by merging the following fields:

<VLAN ID> <STP priority> <bridge MAC address>

When everybody is in the same VLAN, the deciding factor is STP priority … if additionally everybody has same STP priority set (not the case in your case but can be if everybody runs with default value of 0x8000), then MAC address is the winning value.

And root bridge becomes bridge with lowest value from above. IIRC Cisco uses VLAN ID = 0 until switch is set to do VLAN stuff … then it switches over to using “native VLAN” which is usually 1. And if that’s done only on switch which is supposed to be root bridge (most of time) but not on the rest of switches, then one of the rest of switches will win the root bridge selection. I guess that “management VLAN” (or something similar) might be the VLAN ID used on switches with simpler OS running.
Unfortunately this seems to happen even with “plain” STP and RSTP, both are supposed to be VLAN-indifferent.
I guess something similar happens with other vendors’ gear.

There is a good description in the documentation https://help.mikrotik.com/docs/spaces/ROS/pages/21725254/Spanning+Tree+Protocol#SpanningTreeProtocol-Electionprocess

STP & RSTP know nothing of VLANs so you have to ensure that all of your alternate paths carry all of your VLANs. In order to have some VLANs take one path and other VLANs take another path you need to use MSTP.

Cisco invented their own PVST/PVST+ plus protocols before MSTP, this abuses the 12-bit all-zeros field in the bridge priority field to carry the VLAN ID and is incompatible with regular spanning tree standards.

Another gotcha on Mikrotiks is to ensure that the BPDUs are being sent untagged, prior to VLAN-aware bridges it was easily possible to end up with tagged BPDUs which resulted in undefined behaviour, see https://help.mikrotik.com/docs/spaces/ROS/pages/19136718/Layer2+misconfiguration#Layer2misconfiguration-VLANonabridgeinabridge

I’m also unsure what happens when you set the bridge-to-CPU port to have frame-types=admit-only-vlan-tagged - I vaguely recall that there were issues with management packets such as IEEE slow protocols if untagged was disabled in the past. (It’s a pity that the original VLAN specification didn’t include a mechanism to segregate untagged management and user packets, so switch chips and firmware have to allow certain untagged packets through, even when most are disabled.)