I haven't used RoMON (only using in my home). But when I looked at the RoMon documentation link there is this warning specific to the RB5009 switch chip. Whether it would work as as long as frame-types=admit-all was used, I don't know.
info
RoMON packets can be forwarded through network switches or bridges, unless there are specific restrictions on multicast traffic. When using a MikroTik bridge with hardware offloading, these packets are treated like regular multicast packets and are flooded across the network.
Since RouterOS v7.17, if the RoMON service is enabled and the switch chip supports ACL rules, dynamic rules are automatically created to redirect these packets to the CPU, where the RoMON service operates. However, if the switch does not support ACL rules and the configuration does not align, such as when the CPU and RoMON untagged packets are not in the same VLAN, the RoMON service might not function as expected.
RB5009 (switch‑chip 88E6393X) does not support this path. The chip’s frame‑types=admit‑only‑vlan‑tagged filter drops RoMON frames before any ACL rule can be applied, so the packets never reach the CPU.
The restriction probably only applies to frame‑types=admit‑only‑vlan‑tagged, but I can't test that because my RB5009 only has hybrid and access ports, not trunk only ports. With admit-all and admit-only-untagged-and-priority-tagged RoMON works without problem, and my RB5009 has a VLAN-only setup (no address on bridge).
My PC is connected to the RB5009 (A) on one VLAN, and two other RouterOS devices (B & C) are each on their own different VLANs, all these RoMON connection combinations work:
- Connect to A via B
- Connect to A via C
- Connect to B via A
- Connect to C via A
- Connect to A via B
- Connect to C via B
The RB5009 does have a dynamic "Redirect to CPU" switch rule automatically added for the 0x88bf EtherType, as the document says:
So, it probably affects admit-only-vlan-tagged only, OP might need to switch the frame types of the trunk port to admit-all if it doesn't work as expected.
EDIT:
After thinking more about this issue, I guess it only affects the situation where the CPU port is not part of the VLAN. In my screenshot above, it would be those VLAN 124-132 because for those the RB5009 only acts as a switch, with no bridge being tagged for those VLANs. If I had RouterOS devices connected to those VLANs and want to use the RB5009 as intermediary, the "Redirect to CPU" rule would be needed (because otherwise the CPU never sees any packets on those VLANs), and the restriction of that switch chip is that if we want to filter by EtherType 0x88bf, the packets cannot have VLAN headers.
But in case of the other VLANs, like 12, 14, 15, 60, 1000 in my screenshots, the CPU port bridge is a member of the VLAN already and can see the packets with EtherType 0x88bf without needing any switch rules. My tests (and OP's setup because the RB5009 CPU sees all VLANs) would probably still work even with frame-types=accept-only-vlan-tagged.
