Did you understand what @anav wrote? You are using bridge ports as if they were L3 interfaces, and that is a misconfiguration. See IP address in bridge or etherX. Once you add an ethernet port to a bridge device, you should not try to use layer 3 commands with the ethernet port; L3 commands apply to the bridge interface that contains the ports. When a port is not a member of a bridge, then it has both the physical port personality as well as the L3 interface personality, but once it becomes part of a bridge, the “L3 interface” personality is inherited from the bridge or when vlans are in use, the vlan interface.
@anav is correct, you should not have vlan 100 configured for both untagged (pvid=100 on bridge) and a vlan interface for tagged vlan 100. That’s a misconfiguration that may have “worked” in 6.48 but not in v7.10. When you are in “undefined behaviour” territory, expect changes in behaviour between versions. Remove pvid=100 from the following: (if using WinBox set the bridge pvid to 1, which is the default).
/interface bridge
add admin-mac=08:55:31:9C:32:1E auto-mac=no fast-forward=no
ingress-filtering=no name=bridge protocol-mode=none pvid=100
vlan-filtering=yes
Another issue is that you have no “connection” from the Switch ASIC to the CPU defined for the internal “trunk” between the CPU and the Switch ASIC.
Add what is in blue.
/interface bridge vlan
add bridge=bridge tagged=**bridge,**sfp1 untagged=ether1,ether2 vlan-ids=100
add bridge=bridge tagged=**bridge,**sfp1 untagged=ether3,ether4,ether5 vlan-ids=101
If this is a hEX S, this likely “worked” in v6.48 because all bridging was done in software by the CPU, but that is no longer the case in v7.10. Bridge HW vlan-filtering was added in the RouterOS 7.1rc1 (for RTL8367) and 7.1rc5 (for MT7621) versions. After that tagged vlan 100 traffic between sfp1 and ether1 will no longer be seen by the CPU at all, the CPU just “programs” the Switch ASIC registers to tell the ASIC that the SPF is connected to a trunk link with vlan 100 tagged, and ether1 is connected to a device that expects “standard ethernet” with no tag. But the traffic is forwarded at wire speed beteen the ports, with no CPU intervention (other than monitoring RSTP, and this can be a problem until it is fixed).
What device is this? If it is a hEX S, there were major changes to the bridge implementation after v7.1. And there appear to be some current issues with RSTP and HW bridge. See Bridge VLAN-Filter Offload broken on hEXr3? and VLAN-Trunk not working [SOLVED - incorrect BPDU filtering on hAP ax lite HW offloaded trunk ports]