In case when I have a simple vlan setup (e.g. as described in Using Local Forwarding Mode, should I prefer vlan-filtering being on or off? Considering the example above, how would vlan-filtering affect performance / CPU load?

Whether you want vlan-filtering on or off depends on how do you want to treat VLAN tags on ports members of that bridge. The difference boils down to this: if vlan-filtering is off, then bridge acts as a dumb switch and doesn't care about VLAN tags at all so it doesn't do any VLAN separation by its own. If vlan-filtering is on, then bridge will take care that VLANs don't leak through non-member ports.

If all ports are able to do filtering by them selves[*] or ports are trunk ports carrying all VLANs or if you don't care about port security, then you can disable vlan-filtering in your case. If this is not the case, then you want vlan-filtering enabled and you have to properly configure VLAN stuff under /interface bridge port and /interface bridge vlan (and possibly under /interface vlan but that's separate issue and needs to be done regardless the vlan-filtering setting).

[*]interfaces which can deal with VLAN tags by them selves, include ethernet ports run by switch chips (except for some select switch chip types under ROS v6) and wireless interfaces. Appropriate configuration needs to be done in specific configuration subtree, e.g. for ethernet ports that's under /interface ethernet switch and for wireless it's a few properties under /interface wireless.

Alright, that clarifies the picture somewhat.

then bridge acts as a dumb switch

But it's not a dumb dumb switch, i.e. it doesn't push the frame out of all ports if it destination MAC is in its table. So it won't necessarily always leak tagged frames, am I right?

ports are trunk ports carrying all VLANs

With respect to Mikrotik configuration lingo, what constitutes a trunk port? And, while we're here, what constitutes a hybrid port?

With respect to the following lab setup:

• CAP has a VLAN-tagged wlan (which is bridged with all other wlans and physical ethernet ports) but no other VLAN-related config applied
• CAPsMAN is connected to CAP over ethernet (which is bridged with all other wlans and physical ethernet ports) and the only VLAN-related config is `/interface vlan` over the bridge
• CAPsMAN runs DHCP on the vlan interface

Do I understand correctly that DHCP packets (and all other traffic) gets properly routed (vlan <-> rest of the network, no bridge rules and IP firewall is disabled on bridge) because the following happens:

1. Frames from CAP's wireless are automatically tagged / untagged (because the interface is VLAN aware)
2. CAP's wireless client sends a lookup DHCP packet which is then tagged and broadcasted over CAP's bridge and then CAPsMAN bridge
3. CAPsMAN's vlan interface (configured over the bridge) can successfully recognize the tagged frame, untag it and forward it to the DHCP server
4. Every other client (of CAP and CAPsMAN) will receive a leaked tagged frame
5. DHCP server then will reply through CAPsMAN's vlan interface which will tag the frame and send it to the bridge which will either broadcast (leak) it to all other clients or, using the MAC table, send it smartly
6. From now on only broadcasts and frames with unknown MAC destination will get leaked

then bridge acts as a dumb switch

But it's not a dumb dumb switch, i.e. it doesn't push the frame out of all ports if it destination MAC is in its table. So it won't necessarily always leak tagged frames, am I right?

A dumb switch or bridge does forward frames according to MAC<->port table. If table doesn't have entry with dst MAC address, such switch forwards frame to all ports (except ingress port). This is one way which leaks VLANs.
If malicious user just listens to the traffic, he will collect the list of live VLANs in short time (every now and then there will be some frame with yet unknown dst MAC address or a broadcast frame).

Most of NICs have single MAC address and that MAC address is then used for all VLANs that NIC might be member of. If switch receives frame with such dst MAC address, it'll forward frame even if connected device is not member of VLAN marked in frame header. This can be used to send some malucious frame to a device which is member of another VLAN (and should be unaccessible).

Then security: if switch/bridge administrator doesn't set up allowed VLANs per switch/bridge port, then malicious user can freely join any of VLANs flowing through such switch/bridge, including highly protected management VLAN.

And the list of issues continues ... endlessly ...

ports are trunk ports carrying all VLANs

With respect to Mikrotik configuration lingo, what constitutes a trunk port? And, while we're here, what constitutes a hybrid port?

Trunk port is carrying one or more VLANs, all of them tagged.
Access port is carrying single VLAN, which is untagged on wire and tagged in the switch/bridge.
Hybrid port is carrying two or more VLANs, one of them is untagged on wire, others are tagged on wire. All VLANs are tagged in switch/bridge

With respect to the following lab setup:

Addition to point #2: since DHCP lookup is a broadcast, every device member of same (V)LAN will receive that packet. In properly configured VLAN switch/bridge environment that DHCP lookup frame would be restricted to single VLAN, in network with dumb switches/bridges all of devices will get it. Some will notice VLAN tag and discard it (if they are not setup as tagged members of said VLAN), others (with buggy NIC drivers) will pass it to IP layer. In every VLAN there has to be DHCP server (unless all devices in that VLAN have manually set IP settings) and if some DHCP server is behind such a buggy NIC driver, it might even answer to thus DHCP lookup even though it shouldn't (but if all necessary DHCP servers are running on your router this won't happen).

Addition to point #4: after client receives DHCP lease from server, it has to verify that the assigned address is not in use, for that device sends out a broadcast frame (and if some receiver of this broadcast is already using address, it'll reply with unicast frame) .. again some leaking. In theory it is possible to use same IP subnet in different VLANs and in this case the hell would break loose

The rest is fine (I guess).

In most SOHO cases one can live with dumb switches/bridges even if there are some VLANs in the mix. However I higly recommend to go full VLAN on all LAN infrastructure devices when need for first VLAN arises. Specially so if all gear is capable of doing VLANs properly.

Trunk port is carrying one or more VLAN

I meant in terms of Mikrotik configuration commands, i.e. what minimal configuration is needed to be able to label port as Trunk, Hybrid or Access? Or, is it possible that no configuration is necessary. In my example is it valid to label all CAP's ports as Hybrid as they can carry both tagged traffic (because broadcast from VLAN-tagged wlan clients) as well as non-tagged (clients of other wlans and physical ethernet ports)?

In properly configured VLAN switch/bridge environment that DHCP lookup frame would be restricted to single VLAN

In other words with vlan-filtering turned on both routers and bridge vlans set up. Is it possible to have a properly configured (with respect to your comment) VLAN with other conditions you outlined?

but if all necessary DHCP servers are running on your router this won't happen

By "necessary" do you mean "reachable by a leaked VLAN packet"?

In the following example, bridge spans ports ether1, ether2 and ether3. Ether1 is configured as trunk port, ether2 as hybrid port and ether3 as access port. Device (CPU processes) has access to none of them on L2 level though ...

Note that it is not necessary to enumerate ports with pvid set in the list of untagged ports in the last config section, that can be done automagically (I did it to make example more clear).

...

By "necessary DHCP servers" I meant DHCP servers in all VLANs ... as I wrote, MT router will not erroneously trip on frame tagged with VLAN (i.e. frame leaked by other equipment won't do any harm), some other gear might.