Are there any plans to add IGMP Snooping support to bridging, via OpenVPN in particular? IGMP Snooping is supported by Linux kernels since 2.6.34, is there a reason to keep it disabled?
Absence of IGMP Snooping breaks numerous scenarios where Mikrotik is used as a CPE or tunnel concentrator.
last news about IGMP snooping - it i will be considered as a possible additional feature for future releases of RouterOS. Nothing confirmed yet, that it will make it. However it has changed from - never ever 
Has anything changed since then?
no, just that 6.0rc7 could be more stable regarding multicast as previous releases.
That’s good with multicast. I haven’t had problems with it actually. Okay through wifi, but that was just a lucky try, didnt actually thought it would work
IGMP Snooping will be very cool when it will be supported
Will there be any changes for the better, in terms of IGMP proxy?
Hello guys,
any updates on IGMP-Snooping? I guess it’s very simple to implement (one simple sysctl in underlying linux) and actually a “big feature” saving lots of $ for infrastructure switches that could be replaced/eliminated by (say) CCR.
Thanks very much!
-mk
If there is any bug to vote on enabling IGMP Snooping, i’d vote on it. Cause it would be nice to avoid flooding multicast frames on all interfaces in vain.
crs-125 do not have igmp snooping?!? when this functions activated? it’s very important for many isp …
we definitely need igmp snooping, it is usefull on rb750,751,2011 and ccr ccs series …
I’m join to it !!! Snooping & Proxy !!!
RB2011UAS-RM, CCR1016-12G
+1 for IGMP snooping. If not on RouterOS then at least definitely on SwOS
(I can’t imagine a managed switch that does not support igmp snooping and querier functionality)
snooping is still not on the list. However on CRS routers you have multicast forwarding database table.
/interface ethernet switch multicast-fdb
won’t this work with current kernel?..
echo 1 > /sys/devices/virtual/net/bridge1/bridge/multicast_snooping
from my experience from support e-mails and different threads on different forms regarding multicast snooping - snooping is evil.
Snooping is not defined by any RFC, it just is.
There is no promise of compatibility between actual PIM (PIM-SM, PIM-DM, IGMP-proxy as defined by their RFCs) nodes and snooper.
what about RFC 4541?
about compatibility: all features you named are working on layer3 (IP interfaces), and snooping is layer2 feature, it should work inside of a bridge interface, between its ports. so, compatibility is not needed - those areas are not intersected
the title starts with “Considerations for”. It is not binding. as you can see rfc4605 is worded very differently.
If you’re going to enter the access switches market (a really huge one I believe) you will have to implement IGMP snooping. By access switches I mean the L2+/L3 managed switches that ISPs are installing in the end-users’ buildings all over their coverage area, and whose ports are directly connected to the CPEs. It’s common for ISPs nowadays to provide IPTV over multicast service, which is not quite practical if access switches do not supports IGMP snooping.
PS. And while we’re talking about the access switches, similar considerations apply to DHCP and NDP snooping as well.
yes, there’s no strict standards about IGMP Snooping, but can you show me some managed switch (except MikroTik’s ) which doesn’t support it?
rfc4605 defines IGMP proxy, which is implemented already in RouterOS. it works completely on layer3, and it can’t help in case of bridged configuration
IGMP Snooping works on layer2 (between bridge ports, not router IP interfaces) using info sniffed from layer3
there is something already:
/interface ethernet switch multicast-fdb
it is not snooping as it is not dynamic. But at least it is controllable now.