[6.41rc52] IGMP Snooping Flood Issues

NetflashTechnical · Mon Nov 20, 2017 10:06 pm

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".

Any ideas?

NetflashTechnical · Thu Nov 23, 2017 11:13 pm

Nadda?

Better question then: Is immediate leave implemented? I think that might solve this issue... maybe?

NetflashTechnical · Thu Nov 30, 2017 5:11 pm

Update: Issue persists on 6.41rc56

nescafe2002 · Thu Nov 30, 2017 5:44 pm

If you experience version related issues, then please send supout file from your router to support@mikrotik.com. File must be generated while router is not working as suspected or after crash.

w0lt · Thu Nov 30, 2017 6:57 pm

I see the same problem on a CRS-125-1S-2HnD using 6.41 rc56, but then a RB2100UAS-2HnD (using 6.41 rc56), seems to work fine.

-tp

NetflashTechnical · Fri Dec 01, 2017 12:00 am

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?

I see the same problem on a CRS-125-1S-2HnD using 6.41 rc56, but then a RB2100UAS-2HnD (using 6.41 rc56), seems to work fine.

-tp

w0lt · Fri Dec 01, 2017 2:54 am

Not sure if the chipset is the issue. It just does't work. It does work ok on the RB2100..... Go Figure...

w0lt · Wed Dec 06, 2017 8:29 pm

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..

w0lt · Tue Dec 19, 2017 1:44 am

Still have the same problem with ROS 6.41 rc66. The multicast addresses fall off after about five minutes. Mikrotik, are you going to look at this?

NetflashTechnical · Thu Jan 04, 2018 9:06 pm

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?

Misi · Mon Jan 08, 2018 12:35 pm

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.

NetflashTechnical · Thu Jan 11, 2018 4:12 pm

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.

100% Spot On what I'm thinking as well!

105547111 · Tue Feb 06, 2018 12:25 am

Still have the same problem with ROS 6.41 rc66. The multicast addresses fall off after about five minutes. Mikrotik, are you going to look at this?

[Ticket#2018011122005578] RE: IGMP Snooping breaks [...]

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.

Misi · Wed Feb 28, 2018 4:34 pm

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.
100% Spot On what I'm thinking as well!

I did some tests on my CCR with 6.42rc35 and the problem seems to have been resolved.

a4x4kiwi · Mon Mar 26, 2018 9:34 am

Hi,

I have the same problem. RB1100AHx4 using 6.41.3 current.

Same problem.

Is there a ticket logged for this, or does anyone know the last known good version.

Cheers,
Mal

a4x4kiwi · Thu Mar 29, 2018 1:18 am

Hi All,

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.

Cheers,
Mal

smarag · Sun Jul 15, 2018 3:30 pm

I have this setup on CRS328-24P-4S+

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

/interface bridge
add admin-mac=02:BD:3F:3F:6D:8E auto-mac=no fast-forward=no igmp-snooping=yes \
    name=bridge protocol-mode=none vlan-filtering=yes

/interface bridge port
add bridge=bridge interface=ether1 pvid=11
add bridge=bridge interface=ether2
add bridge=bridge interface=ether3
add bridge=bridge interface=ether5 pvid=110 unknown-multicast-flood=no
add bridge=bridge interface=ether6
add bridge=bridge interface=ether7 pvid=11
add bridge=bridge interface=ether8 pvid=200
add bridge=bridge interface=ether9 pvid=200
add bridge=bridge interface=ether10 pvid=200
add bridge=bridge interface=ether11 pvid=200
add bridge=bridge interface=ether12 pvid=200
add bridge=bridge interface=ether13 pvid=200
add bridge=bridge interface=ether14 pvid=200
add bridge=bridge interface=ether15 pvid=200
add bridge=bridge interface=ether16 pvid=200
add bridge=bridge interface=ether17 pvid=500
add bridge=bridge interface=ether18 pvid=200
add bridge=bridge interface=ether19 pvid=200
add bridge=bridge interface=ether20 pvid=200
add bridge=bridge interface=ether21 pvid=500
add bridge=bridge interface=ether22 pvid=500
add bridge=bridge interface=ether23 pvid=110 unknown-multicast-flood=no
add bridge=bridge interface=ether24 pvid=110 unknown-multicast-flood=no
add bridge=bridge interface=sfp-sfpplus1
add bridge=bridge interface=sfp-sfpplus2 unknown-multicast-flood=no
add bridge=bridge interface=sfp-sfpplus3 unknown-multicast-flood=no
add bridge=bridge interface=sfp-sfpplus4
add bridge=bridge interface=ether4 pvid=110 unknown-multicast-flood=no

/interface bridge vlan
add bridge=bridge untagged=\
    sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4,ether2,ether3,ether24 \
    vlan-ids=1
add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 \
    untagged=ether1 vlan-ids=11
add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 \
    vlan-ids=200
add bridge=bridge tagged=sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 untagged=\
    ether4,ether5 vlan-ids=110
add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 \
    vlan-ids=500
add bridge=bridge tagged=sfp-sfpplus1,sfp-sfpplus2,sfp-sfpplus3,sfp-sfpplus4 \
    vlan-ids=510
/routing igmp-proxy interface
add alternative-subnets=0.0.0.0/0 interface=ether5 upstream=yes
add interface=bridge

[6.41rc52] IGMP Snooping Flood Issues

[6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Re: [6.41rc52] IGMP Snooping Flood Issues

Who is online