I just noticed the 'inactive' flag for the bridge port
This is clearly the problem. With an "I" flag and a "disabled" status, the bridge is not going to be forwarding traffic to that member interface since it doesn't consider it to be valid for some reason. The question is why. Normally, I would only expect to see something like that if the VLAN interface itself was disabled, the VLAN interface's parent interface was disabled, or the VLAN interface's parent interface was not in "R"unning state (doesn't have a link). After reviewing your export, assuming it is complete, I am as baffled as you are; everything looks fine to me.
What happens if you try disabling and re-enabling that entry in the bridge port list?
Maybe related; I configured a spare RB2011 (running 6.7 instead of 6.27) with the same config as I shared before (with the DHCP server on the bridge), and it works!
Take the working test router, upgrade it to 6.27, and see if it still works immediately after the upgrade has completed without making any changes. If it doesn't work, check the status of the VLAN in the bridge port membership to verify that the same thing happened to this router after the upgrade ("I" flag).
If the upgrade breaks things in the exact same way, downgrade it back to 6.7 and see if it starts working again. If it does, you are in for a long night: upgrade one minor point release at a time (6.8, 6.9, 6.10, ...) until it breaks again. Then review the changelog once you find the version that breaks it and see if there is anything related in there. Finally, open up a support ticket with MikroTik Support (firstname.lastname@example.org
) giving them all of this information (what is happening, what version of RouterOS caused it to break, along with attaching a supout.rif file generated from the router while it is in the broken state).
The bridge cannot contain the a VLAN that is assigned to a physical port and the physical port itself. I don't know specifically why, ...
Um...because that would be nonsense? What exactly would be accomplished by bridging the VLAN with its parent interface? You want ethernet packets tagged with that VLAN and egressing from that interface to be hairpinned right back around sent back into the same interface that they came from, but stripped of their VLAN tag?
In any case, it doesn't look like 'bjornpost' tried to do that, so that's not the problem here.