Hello,
I have a weird issue with spanning tree on RouterOS 7.3.1: I have a bridge set up on a CRS328, and a bridge on an RB760iGS (hEX S). The CRS328 has ether1 linked to the RB760's ether1.

CRS328 bridge:
RB760 bridge:
When attached to the RB760, I lose connectivity after a few seconds with the following in the CRS328's log (when topics=stp is enabled):
If I swap out the RB760 for an hAP-AC^2 with an identical bridge config, everything works as expected. I've erased, netinstalled, reset and reconfigured the RB760 so many times now I'm not being objective and probably missing something blindingly obvious. I've consulted the block diagrams and as far as I can tell, thisshouldwork.

If I disable MSTP on the RB760, connectivity returns and the CRS328 logs the following:
If I swap out the RB760 for an hAP-AC^2 and leave MSTP enabled,the issue goes away and MSTP works fine.

I'm rummaging around now to see if I have another MMIPS board with a switch chip to see if it's architecture-specific. In the mean time, can anyone spot my obvious mistake?

(Some while later): Tried with an RBM33G and the exact same bridge config - this is also causing the CRS328 to spit out thelearning, discarding, learning, discardingloop, so based on a sample size of two, is this MMIPS-specific?

EDIT: Is this endian-specific? Next test this evening is to try the two MMips boards against each other and see if they work...

Thanks!

which version of RouterOS are you running??

i have an MSTP simple implementation involving an hEX S without problem using 6.48.6

in your config i don't see your configured parameters of MSTP and bridge related to that

consider the possibility of some port flapping on the network causing that

Hi,

which version of RouterOS are you running??

7.3.1 as stated. Routerboard fIrmware is also updated on all devices.

in your config i don't see your configured parameters of MSTP and bridge related to that

As I say, I may have it wrong, but when defaults are enabled in 7.3.1, MSTP works fine simply by including the "protocol mode" and "priority" parameters in the bridge config.This is also working as shown on at least 6 other switches in a different setup with them running 7.3.1. So far, leaving edge port definitions as auto has also worked fine, although that's now something I'll check. Also, if identical config works on one model but not another, curtious why this would change (although not doubting it might!)

Config line that introduces MSTP:Thanks!

In recent versions of routeros 7 hex s received updates to run bridge vlan filtering by hardware, maybe You need to check if disabling bridge hardware offload solves they situation

In recent versions of routeros 7 hex s received updates to run bridge vlan filtering by hardware, maybe You need to check if disabling bridge hardware offload solves they situation

That's a great idea. I'd just found thechip feature compatibility matrixin the new documentation. I'd just figured that if it was an incompatible feature it'd disable hardware offload anyway, but perhaps not. Thanks!

OK - so this has got to be a bug. No changes to config, MMIPS to MMIPS - works fine (and with hardware acceleration, which is a bonus). ARM32 to ARM32 - works fine. ARM32 to MMIPS - no workie.

字节顺序在calc某处,或更多的东西simple?

The test rig is getting a little out-of-hand now...

nice lab you have !!!

Thank you! It all started with an RB750 about 15 years ago. Can't believe I actually get paid to fiddle with this stuff

maybe You need to check if disabling bridge hardware offload solves they situation

Disabling hardware acceleration has fixed the issue.

我与Mikrotik支持和提出了一个问题雷竞技网站y've duplicated it in their labs, with a comment of ..."we are looking forward to fixing it in the future RouterOS versions" - which is encouragingMarking your post as the fix as ultimately this workaround works until the hardware fix is in place. Cheers!

EDIT: Same (software bridge working, hardware offload enabled does not work) in 7.4 also.

Hi,

See the same thing on 24x CRS328-24P-4S+ running v7.4.

Its not just the local MSTP instance that suffers, edge events are propagated downstream as well. Same result except now every edge event results in all switches in the region quitting forwarding for a short while. The downstream propagation only happens if the switch has more than one path. Disable your alternate paths and the edge propagations go away.

Local instance still bounces each time. I have an open ticket on the issue. But it seems you already have an answer, they know and will fix.

Same result except now edge event results in every switch in the region quits forwarding for a short while. The downstream propagation only happens if the switch has more than one path. Disable your alternate paths and the edge propagations go away.

Wow, OK - I was only one switch deep at the time in a lab environment so didn't see anything of that scale. Feel like I've dodged something more substatial now though!

Back to rSTP for awhile

Are there any Updates on this topic?

We've got the same problem at our campus.
18x CRS326-24S+2Q+ on ROS 7.5 as core switches and 45x Dell N1100/N3048 as access switches.
Back to RSTP would be a bit much work...

FYI
From the mikrotik support:

Hello,
Thank you for the report!
We have managed to reproduce the issue locally in our labs and look forward to fixing it on upcoming RouterOS versions, unfortunately, I cannot provide a release date now.
Sadly there is no workaround available, other than running RSTP.
Best regards,