Wed May 08, 2019 2:58 pm
Now wait, that's two different issues, not the same one.
One issue is that the trunking can either be done at bridge level (in software running at CPU) or at switch chip level (in hardware), but not both at the same time, because the decision through which physical interface to run the frame must be done at the same place for frames sent by the CPU and frames forwarded from other interfaces (ports) of the switch chip. So if the decision is to let the switch chip handle the trunking, the trunkX port must be a member port of the bridge as @mkx wrote. So if RouterOS doesn't accept that, it is a bug.
@squeezypiano, can you check whether when you type /interface bridge port add interface= in the CLI (terminal window or ssh) while the trunk has previously been created using /interface ethernet switch trunk add ... and press the [TAB] key, RouterOS suggests you the trunk interface name among the choices? And if not, what about /interface print?
Another issue is how STP makes friends with trunking in hardware. For sure the CRS1xx/2xx switch chips do not support MSTP in hardware so if you activate it on a bridge, direct forwarding in switch chip between member interfaces of that bridge is disabled, but that should by itself not affect the ability to set up a trunk at switch chip level. Older STP flavors are supported by the switch chip itself in hardware, however there may be some headache associated with the trunking. Normally the trunk as a whole must be handled as a single logical port by the STP (otherwise STP would shut down all the member ports but one), so if the hardware STP in the switch chip didn't respect this, there would be an issue. And I agree that regarding this aspect, the manual is audibly silent.