**CCR2004 Bridge IGMP Querier sending 0.0.0.0 untagged on VLAN-filtered bridge — is there a workaround?**

RouterOS
1

Hello MikroTik community,

We are deploying CCR2004-16G-2S+ routers in hospitality/hotel environments for OTT IPTV distribution over a specific VLAN (850). Our setup involves:

  • CCR2004-16G-2S+ running RouterOS 7.22.3
  • Bridge with vlan-filtering=yes
  • VLAN 850 carrying IPTV multicast (source: HUB server, receivers: STBs)
  • ether8 configured as a tagged trunk uplink to a downstream Cisco Catalyst switch
  • STBs connected to Cisco access ports on VLAN 850

The Problem

With multicast-querier=yes enabled on the bridge, we expected the CCR to send IGMP General Queries sourced from the VLAN 850 interface IP (172.18.255.254) tagged on VLAN 850. Instead, when sniffing the trunk port we observe the following:

ether8-STB-Uplink  ->  04:F4:1C:C0:30:4F  01:00:5E:00:00:01  [no VLAN tag]  0.0.0.0  224.0.0.1  igmp

The queries are sent untagged with source IP 0.0.0.0 every 30 seconds. This means:

  1. The downstream Cisco switch (with IGMP snooping enabled) does not recognize these as valid IGMP queries for VLAN 850
  2. The Cisco never dynamically learns the mrouter port toward the CCR
  3. We are forced to configure a static mrouter port on the Cisco (ip igmp snooping vlan 850 mrouter interface g1/0/24) as a workaround t

What we have tried

  • Toggling multicast-querier=no then yes — no change
  • Disabling/re-enabling the bridge — queries fire immediately after startup but still 0.0.0.0 untagged
  • Removing 192.168.88.1 from the bridge interface (queries were briefly sourcing from this address before we removed it)
  • Configuring /routing pimsm instance and interface-template on vlan850 — PIM-SM showed as Designated Router but generated no IGMP queries
  • Removing IGMP proxy interfaces (we had vlan850 upstream + bridge downstream) — no change to querier behavior
  • Upgrading from RouterOS 7.15.3 to 7.22.3 — behavior unchanged

Current workaround

Static mrouter on the Cisco switch works and STB reboot pixelation is resolved. However this is an additional manual step on every property deployment and we would prefer the CCR to act as a proper IGMP querier sourcing tagged queries from 172.18.255.254 on VLAN 850 so the downstream switch learns the mrouter port dynamically.

Question

Is there a supported method in RouterOS 7.x to force the bridge IGMP querier to source queries from the correct VLAN interface IP, properly tagged, when vlan-filtering=yes is enabled? We have seen references suggesting this is a known limitation — is PIM-SM with a properly configured instance the intended solution, and if so what is the correct configuration?

Thank you in advance for any guidance.

Environment:

  • Hardware: MikroTik CCR2004-16G-2S+
  • RouterOS: 7.22.3 (also reproduced on 7.15.3)
  • Bridge: vlan-filtering=yes, igmp-snooping=yes, multicast-querier=yes, multicast-router=permanent
  • Downstream: Cisco Catalyst 2960 series, IGMP snooping enabled, VLAN 850
2

multicast-querier=yes on the router wont work with vlans. make it =no

igmp-snooping=yes on the switches should be coupled with pvid that matches the querier pvid throught the hole network, dont leave one switch without this..

/interface bridge frame-types=admit-only-vlan-tagged igmp-snooping=yes igmp-version=3 mld-version=2 name=bridge1 pvid=850 vlan-filtering=yes

Then enabe pim-sm and only in 1 interface! I found that pvid on the bridge should be the same as the querier vlan. also block vlan id 1 on the switch bridge. This is my 2 cents, not a super detalied solution, maybe not optimal also but i have found it works and I have no more time to mess with it more

3

This is a known and documented limitation:

Only untagged IGMP/MLD general membership queries are generated, IGMP queries are sent with IPv4 0.0.0.0 source address, MLD queries are sent with IPv6 link-local address of the bridge interface. The bridge will not send queries if an external IGMP/MLD querier is detected (see the monitoring values igmp-querier and mld-querier).

The 0.0.0.0 source IP is usually not much of a problem, as generated group membership reports are sent to the 224.0.0.1 group and the querier's source IP does not really matter.
But not being able the send VLAN tagged queries is a severe limitation making the ROS querier unusable as soon as VLANs matter.