I’ve run into an interesting issue with IGMP Snooping while testing on a 6.41rc52 bridge. It looks like when someone is channel surfing or when a port suddenly drops from the bridge, it then floods that stream to all channels for anywhere between 2 and 20 seconds. this can get excessive really quickly if a few people are flipping channels or even if one person is rapidly changing channels, with upwards of a couple hundreds of mbits of traffic suddenly saturating every port on the bridge. It’s like the Mikrotik suddenly doesn’t know what to do with the original stream and just by default decides to dump it to every interface rather than drop the packets.
In fact, a device dropping from the bridge is the worst, because that seems to be the time when it lasts for the full 10-20sec. OR, if I make any change to the bridge manually, like I turned off Fast Forward, bam every stream getting ALL multicast traffic for a dozen seconds. Turn Fast Forward back on, bam every stream getting ALL multicast traffic for a dozen seconds.
For reference, I’m testing with a CCR1017-12S-1S+, IGMP snooping enabled, Fast Forward enabled, STP protocol set to “none”.
Ohhh, good to know! It might be related to which CPU/chipset is doing the snoopin’ because the 2011’s use mipsbe… or at least the specific implementation of it for that chipset.
Were you doing hardware offloading for the bridge on your CRS?
Just tried upgrading a CRS-125 to ROS 6.41 rc61… Still does the same thing..
Dumps IGMP-Snooping addresses after about 5 minutes or so.
Back to the drawing board boys..
Issue persists in 6.41 final. Also tried with a CRS226-24G-2S+RM, same problem when using hardware offloading. Basically makes Mikrotiks useless for IGMP snooping, if someone flips channels too rapidly I can saturate every 1G interface on the switch in a matter of seconds.
EDIT: I think I’ve got a better idea of where the problem is. There’s a delay between when a multicast stream request goes out and when the group gets added to the MDB, in the meantime that stream is coming in and is going to every interface participating in the bridge or switchchip. Maybe an option to drop all traffic not participating in an MDB-listed group might resolve this issue? Or maybe an option for “is in MDB” for the firewall filters so users can add it manually?
I have same problem on CCR1036-12G-4S but this problem not related to hw.
In my configuration different tunnel types(openvpn, l2tp) connected to bridge. In MDB table seems OK. But if a tunnel suddenly breaks down(client loss internet connection, etc.) and virtual interface disappears mcast address also disappears from table and bridge to start sending it to all other interfaces.
In normal operation IGMP snooping blocks traffics if equipment didn’t get IGMP join or report through the interface. In my opinion Mikrotik only blocks if it’s in the MDB table.
In my case its breaking DLNA across my network. Any switch that has IGMP snooping set on the bridge clients start to loose servers. Before too long there’s not a single DLNA server on the network.
There us the solution that has worked for me provided by MT.
By default unknown multicast traffic is flooded, but this can be changed.
You should upgrade to 6.42rc and set unknown-multicast-flood=no on all bridge ports that are carrying any IGMP traffic.
On ether5 have IP streamer and on ether24 have Samsung IPTV and on ether23 have my PC with VLC with see correctly IPTV from streamer the problem after plug or unplug a cable from any port on this switch freeze IPTV from other ports at this switch, start again to play after change channel. Please tell me how to fix this problem. Have routerOS 6.42.5
