VLAN switch and bridge combination - advice please

BrandonSk · October 23, 2020, 4:52pm

Hello,

I am a bit confused about VLAN implementation options. While individual cases are quite clear to me (meaning using either built-in switch chip capable of VLANs, or using bridge for VLANs, …), I am not quite sure if those different methods can coexists in one setup. Therefore I would like to ask you for an adwise how to approach the following scenario with regard to VLANs.

This is a (advanced) home setup.

Main router: CRS112-8G-4S

WAN connection
one NAS connected via bond (802.3ad - 2 interfaces)
one HP ProLiant microserver connected via bond (802.3ad - 2 interfaces)
one bonded (802.3ad - 2 interfaces) link to switch (see below)
CAPsMAN (local forwarding allowed)
two GRE over IPSEC tunnels to other 2 locations (for now, no VLAN needed for those, just so that from those locations I can access resources in this main location)

Switch: CRS125-24G-1S-2hnd-in

bond to the main router (see above)
connections to rooms (either to end devices or to other smart switches [TP-link, VLAN capable] located in rooms which connect end point devices)
besides end-point devices, there are also few AP managed by CAPsMAN (cAP lite)
currently this switch provides DHCP service for the newtork (but this can ofcourse moved to the router if needed)

Note 1: I think I could sacrifice the bonds if a solution that off-loads cpu is possible without them.
Note 2: Switch CRS125 is physically located away from the router, so it is not possible to connected the NAS/Server into the switch instead of the router. In the worst case I can imagine inserting one more router in front of the CRS112 if that would help :-\

Goal: To have separate VLANs for Guests/Kids/internalLAN/servers/managementVLAN (for the sake of simplicity, we can consider just 2 VLANs for now - internal and guests)

I was able to create VLANs on my “LAB” (CRS109 & CRS125 - should be the same as production, the only difference from VLAN perspective is the inability of CRS109 to do VLAN ACL):
A) using the built in LAN switch on both of these devices.
B) I was also able to create working VLANs via bridge. Both using guides on mikrotik WiKi.
I ran into problems (vlans not working, e.g. not getting an ip etc.) as soon as:

I tried including the bonds into the setup (also changing the bond from 802.3ad into Trunk connection in switch menu for switch to router bond, and also the balance-xor bond for router-to-server/nas connection).
I also was not able to get the VLANs working for CAPsMAN managed APs (although in this case I am not connecting to cAP lite, but hAP lite - but that should not matter).

Questions:

What is your recommendation for overall setup, given the target scenario?
Is it possible to combine VLAN methods (switch/bridge) on one device (e.g. physical ports VLANs via switch chip and bonds/caps via bridge VLAN), or do I have to choose one and stick with it? (my undestanding is, that in my setup using devices I have if I can choose only 1 method, then I cannot utilize the built-in switch chip, as I will need bridge method for CAPs and bonds).
Is it possible (later on) to assign VLANs also to clients connecting from remote locations via the GREoverIPSEC tunnel?

Thanks a lot for your suggestions. If I should inlcude more information, please let me know.

Cheers,
Brandon.

mkx · October 23, 2020, 6:45pm

My 5 cents (and won’t follow your sequence of questions

2)
While ROS won’t reject configuration which mixes both approaches (hardware vs. bridge), the result will likely not function well. So when it comes to devices with poor CPU (and/or slow CPU-switch chip interconnect), I would stick to hardware approach. Some parts of setup get slightly complicated (e.g. the GRE tunnels which don’t have any VLAN setup and that has to be supported by other means), but what can be, will be offloaded to hardware.
The complicated part can be something like adding GRE tunnel (transporting untagged packets) to certain VLAN. In bridge VLAN scenario it would be simple /interface bridge port add interface=gre pvid=666 while in HW scenario it would be more complex:

/interface vlan
# extract packets with VLAN ID 666 from grand bridge
add interface=bridge name=bridge_v666 vlan-id=666
/interface bridge
# create bridge for VLAN 666 traffic untagged and add interfaces which should carry that traffic
add name=bridge666
/interface bridge port
add bridge=bridge666 interface=bridge_v666
add bridge=bridge666 interface=gre

Handling of GRE packets will be slightly less efficient, but CPU will be relieved from handling intra-VLAN traffic between ether ports.

1)
If you’re not very familiar with ROS (yet), then you may want to go with bridge VLAN concept, it will be quite simpler setup. Performance wise hardware concept will probably be better performing unless most of traffic involves routing or GRE tunnels.
In your particular case I’d go completely different direction: I’d keep using CRSes for what they really are (they are switches with management interface on steroids) and I’d fetch a couple of cheap devices with beefier CPUs for routing. If you’re on tight budget, a RBD52G would make a great router, can offload IPsec encryption to dedicated hardware as well. If you can spend some more serious bucks, you can go for a RB4011 (still an all-in-one SoHo device) or some CCR device.

3)
GRE tunnel is a virtual L2 connection and since VLAN is “L2.5” thre’s no reason why VLAN tags couldn’t pass GRE tunnel to the remote end. If you are going that way, I suggest you to go with bridge VLAN way, because example configuration I showed in answer to question #2 would get even more complex for each VLAN passing GRE tunnel (add vlan interface also on top of gre interface) and you’d have one such monster per VLAN passing through GRE. Unless you’d pass all VLANs, then setup would become dead simple (simply adding GRE tunnel interface to the general bridge). With bridge VLAN concept, you just omit the pvid setting and add GRE tunnel interface as tagged interface for appropriate VLAN IDs.

sindy · October 23, 2020, 6:54pm

Everything correct above if you replace “GRE” by “EoIP”. GRE as such is “Generic”, but what Mikrotik calls GRE is just one of the applications of GRE, which is an L3 tunnel; what Mikrotik calls EoIP is another application of GRE, which is an L2 tunnel (and for some weird reason, Mikrotik has decided to implement a proprietary misuse of the optional GRE ID for EoIP rather than using a standard GRETAP encapsulation, like they apparently did with EoIPv6).

mkx · October 23, 2020, 6:58pm

Thanks for correcting me.

sindy · October 23, 2020, 7:03pm

A big black point to whoever has decided to disable PM again a few days ago, I’d have used it instead if that was still possible.

anav · October 23, 2020, 7:05pm

So is using VLANs with EOIP a. possible, and b. recommended?

sindy · October 23, 2020, 7:39pm

a. yes, you can use the EoIP tunnel the same way as if it was just an unusually long section of an Ethernet cable
b. any L2 tunnel is a trade-off. It wastes your bandwidth for the broadcast traffic (ARP and other), and even for unicast traffic, it has to split each frame to two packets as you cannot use clever tricks like PMTU discovery

c. if you don’t use local forwarding on the cAP, an L3 link is sufficient to connect it to the CAPsMAN, because the virtual wireless interfaces are created on the CAPsMAN device, and get tagged/untagged there if necessary.
d. connecting cAPs to a CAPsMAN via any kind of tunnel via WAN is another tricky thing, as even a very short interruption of the link causes the cAP to lose connection and re-establish it.

BrandonSk · October 24, 2020, 9:19pm

Thank you everyone for the replies.
I realize that my original post was perhaps too broad, but I wanted to get a feeling “IF it is possible” and HOW to go about it. I will continue trying step by step and slowly expanding my lab, until I get it right

Speaking of which - I have a little progress. I narrowed my lab setup down to router CRS109 (GW) and one AP (CAP), which is a RB952Ui-5ac2nD (but I only pretend it has ether1 and wlan1)

On the router I setup VLANs, DHCPs and dedicated few ports as access ports and few as trunk ports.
What works - when I connect clients to access ports, they get an IP from the correct DHCP server and can browse the internet. From my perspective VLANs on router work as they should.

On ether6 I am runnign VLAN30.

If I connect PC to ether6, everything works as expected (IP from VLAN30 range, connection to internet).
When I connected the AP to ether6 and ran DHCP client on the AP (either on ether1 or the bridge), I do get correct IP assigned from DHCP (VLAN30 range).
Then I removed the client and turned on CAP on wlan1 interface. It connects to CAPsMAN (running on the GW) and starts providing WiFi. I can connect to the wifi and get authenticated.
(!) however, I do not receive an IP address.
(I tried different combinations assigning tagged/untagged to bridge, ether1, etc., but non of it was a success).

Here are my configs and I would appreciate if you can push me a little further so that I can get the wifi working. Thank you!

GW (CRS109):

# oct/24/2020 22:19:54 by RouterOS 6.47
# software id = WRL1-JR0T
#
# model = CRS109-8G-1S-2HnD
# serial number = 522D0463C99F
/interface bridge
add name=bridge
/interface wireless
set [ find default-name=wlan1 ] ssid=MikroTik
/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN
set [ find default-name=ether2 ] name=ether2-direct-notSwitched
set [ find default-name=ether3 ] name=ether3-Link1of2
set [ find default-name=ether4 ] name=ether4-Link2of2
set [ find default-name=ether5 ] name=ether5-vlan-open
set [ find default-name=ether6 ] name=ether6-vlan30
set [ find default-name=ether7 ] name=ether7-vlan-PC
set [ find default-name=ether8 ] name=ether8-vlan-raspberry
/interface vlan
add interface=bridge name=MGMT vlan-id=99
add interface=bridge name=VLAN10 vlan-id=10
add interface=bridge name=VLAN20 vlan-id=20
add interface=bridge name=VLAN30 vlan-id=30
/caps-man configuration
add country=slovakia datapath.bridge=bridge datapath.local-forwarding=yes \
    datapath.vlan-id=30 datapath.vlan-mode=use-tag name=config_Work \
    security.authentication-types=wpa-psk,wpa2-psk security.passphrase=\
    123456 ssid=WiFiWork
/interface ethernet switch
set drop-if-invalid-or-src-port-not-member-of-vlan-on-ports="ether3-Link1of2,e\
    ther4-Link2of2,ether7-vlan-PC,ether8-vlan-raspberry,ether6-vlan30"
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp_pool0 ranges=10.10.10.2-10.10.10.254
add name=dhcp_pool1 ranges=10.20.20.2-10.20.20.254
add name=dhcp_pool2 ranges=172.16.16.2-172.16.16.254
add name=dhcp_pool3 ranges=10.30.30.2-10.30.30.254
/ip dhcp-server
add add-arp=yes address-pool=dhcp_pool0 disabled=no interface=VLAN10 name=\
    dhcp1
add address-pool=dhcp_pool1 disabled=no interface=VLAN20 name=dhcp2
add address-pool=dhcp_pool2 disabled=no interface=bridge name=dhcp3
add address-pool=dhcp_pool3 disabled=no interface=VLAN30 name=dhcp4
/caps-man manager
set enabled=yes
/caps-man manager interface
set [ find default=yes ] forbid=yes
add disabled=no interface=bridge
add disabled=no interface=VLAN30
/caps-man provisioning
add action=create-dynamic-enabled master-configuration=config_Work
/interface bridge port
add bridge=bridge interface=ether5-vlan-open
add bridge=bridge interface=ether6-vlan30
add bridge=bridge interface=ether7-vlan-PC
add bridge=bridge interface=ether8-vlan-raspberry
add bridge=bridge interface=*10
add bridge=bridge interface=ether3-Link1of2
add bridge=bridge interface=ether4-Link2of2
/interface ethernet switch egress-vlan-tag
add tagged-ports="ether3-Link1of2,ether4-Link2of2,ether7-vlan-PC,ether8-vlan-r\
    aspberry,switch1-cpu" vlan-id=99
add tagged-ports=ether3-Link1of2,ether4-Link2of2,switch1-cpu vlan-id=10
add tagged-ports=ether3-Link1of2,ether4-Link2of2,switch1-cpu vlan-id=20
add tagged-ports=ether3-Link1of2,ether4-Link2of2,switch1-cpu vlan-id=30
/interface ethernet switch ingress-vlan-translation
add customer-vid=0 new-customer-vid=10 ports=ether7-vlan-PC
add customer-vid=0 new-customer-vid=20 ports=ether8-vlan-raspberry
add customer-vid=0 new-customer-vid=30 ports=ether6-vlan30
/interface ethernet switch vlan
add ports="ether3-Link1of2,ether4-Link2of2,ether7-vlan-PC,ether8-vlan-raspberr\
    y,switch1-cpu" vlan-id=99
add ports=ether3-Link1of2,ether4-Link2of2,ether7-vlan-PC,switch1-cpu vlan-id=\
    10
add ports=ether3-Link1of2,ether4-Link2of2,ether8-vlan-raspberry,switch1-cpu \
    vlan-id=20
add ports=ether3-Link1of2,ether4-Link2of2,ether6-vlan30,switch1-cpu vlan-id=\
    30
/ip address
add address=192.168.99.1/24 interface=MGMT network=192.168.99.0
add address=10.10.10.1/24 interface=VLAN10 network=10.10.10.0
add address=10.20.20.1/24 interface=VLAN20 network=10.20.20.0
add address=172.16.16.1/24 interface=bridge network=172.16.16.0
add address=10.30.30.1/24 interface=VLAN30 network=10.30.30.0
/ip dhcp-client
add disabled=no interface=ether1-WAN
/ip dhcp-server network
add address=10.10.10.0/24 gateway=10.10.10.1
add address=10.20.20.0/24 gateway=10.20.20.1
add address=10.30.30.0/24 gateway=10.30.30.1
add address=172.16.16.0/24 gateway=172.16.16.1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-WAN
/lcd interface pages
set 0 interfaces="ether1-WAN,ether2-direct-notSwitched,ether3-Link1of2,ether4-\
    Link2of2,ether5-vlan-open,ether6-vlan30,ether7-vlan-PC,ether8-vlan-raspber\
    ry,sfp1"
/system clock
set time-zone-name=Europe/Bratislava
/system identity
set name=GW
/system logging
add topics=caps

AP1 (RB952Ui):

# jan/02/1970 00:12:35 by RouterOS 6.47.4
# software id = HEJX-IA0M
#
# model = RB952Ui-5ac2nD
# serial number = 9E940A0DF21C
/interface bridge
add name=bridge1 vlan-filtering=yes
/interface wireless
# managed by CAPsMAN
# channel: 2412/20-Ce/gn(18dBm), SSID: WiFiWork, local forwarding
set [ find default-name=wlan1 ] disabled=no ssid=MikroTik
set [ find default-name=wlan2 ] ssid=MikroTik
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge1 interface=ether1
/interface bridge vlan
add bridge=bridge1 tagged=ether1 vlan-ids=30
/interface wireless cap
# 
set bridge=bridge1 discovery-interfaces=bridge1 enabled=yes interfaces=wlan1

mkx · October 24, 2020, 9:44pm

I’d say you have naming clash: on CRS in capsman configuration you set datapath.bridge=bridge while bridge on RB952 is named bridge1 … and with local forwarding enabled datapath.bridge refers to bridge on CAP device, not on capsman device.

anav · October 24, 2020, 9:48pm

capsman is just another level of management on the router that will continue to compound the number of errors that can be made in a config.
If you only have one or two APs save yourself the grief…

anav · October 24, 2020, 10:07pm

As for the first config… It highlights the main issue from me… incomplete config.
Where is the IP pool for the management vlan and the DHCP Server and the dhcp-server-network??

Also doing the thing I detest…asking the bridge to do dhcp serving instead of simply creating another vlan.
In any case, thats fine.

The second thing I destest is any chip switch configuration, chips are for kids, chocolate chips is the only chip I like
Such a convoluted config style…
I cannot decipher the gobblity gook so hopefully someone else can.

What traffic goes on etherport 2???

BrandonSk · October 25, 2020, 12:09pm

Thanks again for responses.

I renamed the bridge on the CAP device, however it did not resolve the situation of wifi clients not getting an IP.

The Management IPs are assigned manually. But a lot of configuration on the CRS was there to show that VLANs through physical interfaces work and it’s only the WiFi that is having trouble.

I was under the impression that off-loading to switch chip was the preferred way, especially on CRS series… Is that wrong understanding? (otherwise I do not see the point of having that feature at all)

Well, that is for lazyness I have a cable connected to ether2 which I use if for whatever reason I loose the ability to connect to the device through other ports due to configuration. So ether2 is there, not being switched, it is just direct connection in case everything else fails.

True… but for me this is a matter of understanding and learning. After all, it should work at the end, shouldn’t it?

Unfortuanately, I am starting to believe that VLANs are either poorly implemented or poorly documented. I don’t like blaming Mikrotik, but I think this area is a mess and should be greatly simplified (I even bought an Udemy course, which works nicely, but deals just with basic setups, and I am trying to expand on those).

So (to emphasize my point with regard to documentation), after all that ordeal, I reset configuration on both and went with this:
https://wiki.mikrotik.com/wiki/Manual:CAPsMAN_with_VLANs

Guess what - it’s not working. Here is the config from my devices:

GW - CRS109 (changes to wiki are: VLAN10 is VLAN30, ether1 is ether6, ether1 is WAN port with dhcp-client, srcnat, and 2 fw rules on input)

# oct/25/2020 11:32:49 by RouterOS 6.47
# software id = WRL1-JR0T
#
# model = CRS109-8G-1S-2HnD
# serial number = 522D0463C99F
/caps-man configuration
add country=slovakia datapath.local-forwarding=yes datapath.vlan-id=30 \
    datapath.vlan-mode=use-tag name=Config_WORK \
    security.authentication-types=wpa-psk,wpa2-psk security.passphrase=\
    12345678 ssid=WiFi_WORK
/interface bridge
add name=bridge1 vlan-filtering=yes
/interface wireless
set [ find default-name=wlan1 ] ssid=MikroTik
/interface ethernet
set [ find default-name=ether1 ] name=ether1-WAN
/interface vlan
add interface=ether6 name=VLAN30 vlan-id=30
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp_pool30 ranges=10.30.30.2-10.30.30.254
/ip dhcp-server
add address-pool=dhcp_pool30 disabled=no interface=VLAN30 name=dhcp30
/caps-man manager
set enabled=yes
/caps-man manager interface
set [ find default=yes ] forbid=yes
add disabled=no interface=ether6
/caps-man provisioning
add action=create-dynamic-enabled master-configuration=Config_WORK
/interface bridge port
add bridge=bridge1 interface=ether6
/interface bridge vlan
add bridge=bridge1 tagged=ether6 vlan-ids=30
/ip address
add address=10.30.30.1/24 interface=VLAN30 network=10.30.30.0
/ip dhcp-client
add disabled=no interface=ether1-WAN
/ip dhcp-server network
add address=10.30.30.0/24 gateway=10.30.30.1
/ip firewall filter
add action=accept chain=input dst-port=8291 protocol=tcp
add action=accept chain=input dst-port=22 protocol=tcp
/ip firewall nat
add action=masquerade chain=srcnat
/system clock
set time-zone-name=Europe/Bratislava

AP

# jan/02/1970 01:31:36 by RouterOS 6.46.6
# software id = 6BLA-FFMC
#
# model = RouterBOARD mAP L-2nD
# serial number = 95DA0905952B
/interface bridge
add name=bridge1
/interface wireless
# managed by CAPsMAN
set [ find default-name=wlan1 ] ssid=MikroTik
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge1 interface=ether1
/interface wireless cap
# 
set bridge=bridge1 discovery-interfaces=bridge1 enabled=yes interfaces=wlan1

So I really don’t understand now I even tried two different AP devices to rule out that the device is faulty. Do you see a problem in that configuration? Can you provide me an example of a working VLAN on WiFi configuration, which I could replicate in my setup?
Thanks.

sindy · October 25, 2020, 1:49pm

Have you read @anav’s automatic signature carefully? It’s worth it.

The point with CAPsMAN configuration is the following:

if the datapath row indicates local-forwarding=no, the bridge indicated on that row refers to a bridge on the CAPsMAN device. All frames received from the air by the cAP device get encrypted and packed into DTLS packets and transported to the CAPsMAN one, unpacked and decrypted there, and sent to the indicated bridge, as the virtual wireless interface is created on the CAPsMAN machine and made a member port of the bridge indicated on the corresponding datapath row.
- if the datapath row indicates local-forwarding=yes, the bridge indicated on that row is ignored. The virtual wireless interface is created on the cAP device itself, and made a member port of the bridge indicated in the /interface wireless cap configuration on the cAP.

Your VLAN configuration has two issues:

the row of /interface bridge actually holds configuration items for two distinct objects - the actual bridge (an emulator of a hardware switch) and a virtual “Ethernet” interface connected to that virtual switch. So when specifying membership of bridge ports in VLANs in the /interface bridge vlan table, for each VLAN which the router itself needs to access, you have to add the bridge to the tagged or list of ports on that VLAN’s row. So add bridge1 to the tagged list for vlan-ids=30 to the already present ether6.
- you can either make an Ethernet interface a member port of a bridge, or you may attach /interface vlan directly to that Ethernet interface. Not both at a time. So change the interface value on your single /interface vlan row from ether6 to bridge1.

Your firewall rules effectively do nothing at all. The default handling in each chain is “accept”, so a packet which has passed through the whole chain without matching any rule is accepted. So a bunch of accept rules followed by “accept the rest” makes little sense. Have a look what a stateful firewall means and check the firewall rules in the default configuration ( system default-configuration script print).

anav · October 25, 2020, 1:59pm

If this router is attached to the internet and these are the fw filter rules the OP has put in, then there is no point in fixing any capsman or vlans until the OP understands the purpose of the firewall and how to put in a safe config (default for starters is good).

BrandonSk · October 25, 2020, 5:33pm

Gentlemen, thank you for caring Maybe you missed it, but this is a lab setup, not a production one. I am at home, and what you see as gateway/router in my configs is a device which on its “WAN” interface is connected to my home lan. That home lan is rather well secured when it comes to the “real” outside world. I dare to say I am no noob when it comes to that (I also run ipsec tunnels to other locations, and that requires a bit more firewall rules than just opening ports ).
I do agree that the 2 input rules I have are useless. I put them there because later on (if the VLANs work) I plan on implementing fw rules and I wanted to keep an access from “WAN” (my home lan) if necessary.

Now, that’s hopefully settled, but I do agree I am a noob when it comes to VLANs.

@sindy - thank you very much for your explanation. Spot on!

Your VLAN configuration has two issues:

the row of /interface bridge actually holds configuration items for two distinct objects - the actual bridge (an emulator of a hardware switch) and a virtual “Ethernet” interface connected to that virtual switch. So when specifying membership of bridge ports in VLANs in the /interface bridge vlan table, for each VLAN which the router itself needs to access, you have to add the bridge to the tagged or list of ports on that VLAN’s row. So add bridge1 to the tagged list for vlan-ids=30 to the already present ether6.

you can either make an Ethernet interface a member port of a bridge, or you may attach /interface vlan directly to that Ethernet interface. Not both at a time. So change the interface value on your single /interface vlan row from ether6 to bridge1.

That did the trick and everything came up immediately. But most of all it nicely cleared up my confusion when and what to tag. I need to think more deeply what is getting tagged and where.
But that comes back to my complain - documentation is (for me) not so clear.

OK, now I will go and try to build on this by adding second switch, trunk ports and get APs working from the second switch. If I run into trouble, I’ll be back!

One last question that remained unaswered and for me (and others also) could prove useful:

I was under the impression that off-loading to switch chip was the preferred way, especially on CRS series… Is that wrong understanding? (otherwise I do not see the point of having that feature at all)

So given that question, is using the bridge vlan the right way to go, or should I try to achieve the same via the switch chip?

Thanks again to everyone for their contribution!

mkx · October 25, 2020, 5:51pm

The “new” bridge vlan type is unified accross all ROS devices and thus nice to have. It also simplifies configuration on devices without switch chip (most notably CCR line).
But it is run by devices’ CPU and on most devices this means worse performance … except on CRS3xx line where bridge vlan gets HW offloaded and on devices without switch chip where CPU deals with all packets anyway.

Keeping that in mind it is often preferable to configure VLANs in “old school” way on switch chips. Most of MT devices with switch chips can handle VLANs in hardware, although with some limitations (e.g. MAC cache length or even number of VLANs actively configured). Some MT devices with switch chips can not handle VLANs in hardware despites switch chips could do it - the limitation is due to MT’s implementation and currently affects devices which have switch chips not done by Broadcom (in particular Mediatek and Realtek).

sindy · October 25, 2020, 6:25pm

Keby nebolo tých dvoch pravidiel, vôbec by ma nenapadlo uvažovať o inej variante.

I agree with you that the fact that the term “bridge” actually addresses two distinct objects is not explained anywhere in the documentation. I needed a kick in the right direction from @mkx.

That’s a complex subject. The point is that the various Mikrotik products use switch chips of very different capabilities. So when you use bridge, you have the same capabilities on all routerboard models, but everything is done by the CPU. When you permit “hardware accelerated bridging”, which is actually direct frame forwarding by the switch chip, on most routerboard models you have a limited set of switching capabilities like various flavors of STP, port isolation, per-VLAN forwarding database, bonding. On CRS3xx, these functions are available in the switch chips, and only for this product line the bridge’s “hardware acceleration” goes so deep that you may basically ignore any direct switch chip configuration except switch rules.

In addition to the above, the wireless interfaces are always connected to the switch chip via CPU, so the “hardware acceleration” does not work for them.

So on CRS3xx, configure the bridge with hardware acceleration allowed, and you’ll get most of the L2 functionality server by the switch chip (the CRS3xx’s CPUs are usually too weak to handle the traffic otherwise); the hAP/hEX models are not primarily intended as switches with advanced L2 functionality, so if you want to use them that way, you have to use bridging on CPU.