HI there,
I don't know why, but my bridge is acting as a hub. It floods every port in the bridge with packets. As far as I remember, I always had that problem.
RB2011UiAS-2HnD-IN hEX PoE connected to switch2\ether5 Is this normal, this is how it should work? I hope not...

Not normal unless you have something broadcasting. More likely a loop somewhere in L2 land. Look at the logs, Export your configs, especially any switch configs on both routers and post.

Sorry, I could not reply earlier.

I attached more detailed pictures of my setup.
I really don't know why this is happening. Surprisingly, this situation does not occur on different bridges, only on the first one(trunk).

Sorry, I could not reply earlier.

I attached more detailed pictures of my setup.
I really don't know why this is happening. Surprisingly, this situation does not occur on different bridges, only on the first one(trunk).

It boils down to how bridges and switches work. A bridge maintains a map between MAC addresses and ports. When the bridge decides where to send a frame for a unicast MAC address, it searches the map. If it finds a port to which the MAC address is associated, it sends the frame only to that port; if it doesn't, it sends the packet to all ports. The reason is that the map is built based on source MAC addresses of incoming frames.

So until a bridge receives a frame from a given unicast MAC address, it sends all frames for that MAC address to all ports. The same is the case for multicast addresses, i.e. all whose least significant bit of the first byte of the MAC address is 1. Broadcast ARP requests are the most straightforward example of frames using a multicast destination MAC address.

Note that bridges use only the source MAC address of a frame for learning. So if a connected element sends an ARP response whose response part indicates a MAC address other than the source MAC address in its Ethernet header, the bridge remembers the latter but the sender of the ARP request will start sending to the former, so the bridge will send the packets from that host to all ports. Some redundancy protocols build on this feature.

The MAC address table in most bridges has a limited capacity, so if more source addresses than the table size arrive to the bridge, the oldest records in the table are overwritten. This works well in most situations, but if the network is really huge or if someone intentionally floods a bridge with bogus MAC addresses, the bridge starts acting as a hub for most frames while the attack continues.

Another issue is looping. As there is no hop counter in an Ethernet frame, if a frame sent out from a bridge arrives back to it, the bridge sends it out again. This is why Ethernet loops must be avoided. If the loop passes through a bandwidth limiting and/or delay introducing element, it may not clog the bridge completely and normal traffic can pass through as well.

So use packet sniffer and Wireshark to inspect the Ethernet headers and see which of the cases described above causes your issue.

I know how bridge/switch supposed to work. The problem is that this is a unicast traffic, not broadcast nor multicast.
The bridge has both mac addresses in host table and it still floods whole bridge.
When I connect my PC to that bridge I'm receiving that whole traffic as well.

Sorry, I haven't found this important detail anywhere in your description.

Sorry, my bad.
I thought that pictures in the first post show that clearly.

It was said earlier, but I'd like to re-emphasize that low end "switches" have MAC tables that are easily overrun and they start acting like hubs in a hurry in enterprise situations. I have to deal with that all the time. Not to mention when people plug these in and cause L2 loops because they have no protection for that.

This is not a problem. Like I said earlier, host table contains both mac-addresses.

Well, to deny @acruhl's assumption it is necessary to say whether it contains only the two ones or thousands of others as well

I've tried to look at your pictures again but the only MAC addresses I could see there were those of CAP interfaces.

I would suspect overlooking some bit somewhere, i.e. that the learned MAC address and the destination MAC address differ in that bit somewhere in the middle. Can you provide the result of "/export hide-sensitive" after replacing IP addresses with some bogus ones while maintaining the relationship between them (so that, as an example of what I have in mind, not because dhcp settings would be related to your issue in any way, the relationships between local IP address, dhcp pool and dhcp network settings would remain visible)? Also, can you post the result of also obfuscated to show the important information without compromising privacy?

I've noticed that you use a bunch of VLAN interfaces so maybe this is related: if a packet is tagged with a wrong VLAN ID, it may be flooded everywhere if the ethernet host table takes VLAN IDs into account (which is the case if vlan-filtering is on but as you say "it always behaved like this", you probably don't have vlan-filtering enabled).

Right now I have only two exports. From RB2011 and RB912. Config of the third one(hEX) is quite big, so I will attach it tomorrow.

The problem occurs even with just two of them connected directly.

UPDATE BELOW

I directly connected RB2011 with RB912, disabled every interface, besides those which you can see in the picture.
Then set up only one Wireless interface(wireless1 on RB2011) with VLAN Tagging 221. That wireless interface is part of bridge "bridge0-ban1"(trunk) on RB2011.
Then connected one PC wirelessly, another via Ethernet to "switch1\ether2"(which is part of "bridge4-han3" on RB2011 as well) and started btest between them.
The problem occurs even then. You can see that on RB912 which is connected to "switch1\ether5"(part of "bridge0-ban1" on RB2011). RB912 can hear everything, even though both clients are NOT connected to him.
As you can see, "bridge0-ban1" on RB2011 don't know where to find "PC 2", because VLAN interface "bridge0\vlan4-han3" is not part of the bridge. I mean, he is not a port of that bridge. He is like a part of himself. I think this is the problem.