Difference between igmp_snooping on switch and interface section

Hi there! I want to enable igmp_snooping on my router to prevent multicast flooding in my wifi.
I'm using IPTV streaming (based on IGMPv3) with igmpproxy which is working fine! Now I enabled IGMPv3 and igmp_snooping on the switch layer and also in the interface section:

config interface 'lan'
        option type 'bridge'
        option igmp_snooping '1'
        option ifname 'eth1.1'
        option proto 'static'
        option ipaddr '192.168.1.1'
        option netmask '255.255.255.0'
        option ip6assign '60'
[...]
config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'
        option igmp_snooping '1'
        option igmp_v3 '1'

With this config I see after swconfig dev switch0 show | less:

Global attributes:
        enable_vlan: 1
        enable_mirror_rx: 0
        enable_mirror_tx: 0
        mirror_monitor_port: 0
        mirror_source_port: 0
        arl_age_time: 300
        arl_table: address resolution table
Port 0: MAC a4:2b:b0:xx:xx:xx
Port 5: MAC ac:6f:bb:xx:xx:xx
Port 5: MAC cc:1b:e0:xx:xx:xx
Port 5: MAC 7c:2f:80:xx:xx:xx
Port 5: MAC 5c:f4:ab:xx:xx:xx
Port 5: MAC 64:70:02:xx:xx:xx
Port 5: MAC 64:70:02:xx:xx:xx
Port 5: MAC 50:c7:bf:xx:xx:xx
Port 5: MAC 84:b5:9c:xx:xx:xx
Port 6: MAC a4:2b:b0:xx:xx:xx
Port 6: MAC 00:21:6a:xx:xx:xx
Port 6: MAC 24:77:03:xx:xx:xx

        igmp_snooping: 1
        igmp_v3: 1
Port 0:
        mib: MIB counters
RxBroad     : 1
RxPause     : 0
[...]

But now my IPTV streaming stops working. In the OpenWRT documentation the switch commands are labeled as experimental.
If I just comment out the igmp_snooping and igmpv3 in the switch section and let igmp_snooping in the interface section active, my IPTV is working again.
The switch shows then following:

root@OpenWrt:~# swconfig dev switch0 show | grep igmp
        igmp_snooping: 0
        igmp_v3: 0
        igmp_snooping: 0
        igmp_snooping: 0
        igmp_snooping: 0
        igmp_snooping: 0
        igmp_snooping: 0
        igmp_snooping: 0
        igmp_snooping: 0

So my question is: where should I enable igmp_snooping and igmpv3 why it is in conflict with igmpproxy?

Thanks in advance!

If you want to stop Wi-Fi flooding, the option in lan interface is enough.

1 Like

Okay, thanks! Is igmp_snooping in the interface section driver based and maybe slower than enabling it on the switch itself?

It is not the matter of slow or fast. You don't need it at the switch side. The lan bridge won't let multicast to wifi unless it's requested from there.

2 Likes

After one year I'm coming back to this thread. :slight_smile:

I'm using my TP-Link Archer C2600 with OpenWRT in my homeoffice. It's connected to a TP-Link switch in the basement and a Speedport Smart 2 in modem mode as my VDSL2 modem.

Basically it looks like this: ISP <=> VDSL2 modem <=> TP-Link switch (managed) <=> TP-Link Archer C2600

Nearly everything is connected to my TP-Link switch in the basement which handles VLAN and IGMPv3 and IGMP snooping. So if I use my ISP-IPTV-box my network after the switch in the basement doesn't get flooded.

For obvious reasons I connected a Raspberry Pi 4 next to me in the office directly to the C2600 router and noticed the flashing network ports if my IPTV-box is in use. My big core switch in the basement handles the IGMP snooping right but not the C2600 itself.

So I know I want to get IGMP snooping running on the switch of the C2600 to prevent the other ports getting flooded by multicast packets. So long story short: I'm back here because I still want to get the hardware based IGMP snooping working. I know first I have to run through the whole update process of OpenWRT but I still want to understand how to configure it right.

Hey @Ultrazauberer

Any chances you are on a vdsl line from dtag? If so, would you like to share some details which devices have which vlan and where do you had enabled igmp_snnoping and which igmp proxy you are using and how its config looks like? Setup IPTV is next on my todo list and your setup seams to look like similar to mine.

Yes, I use MagentaTV from Deutsche Telekom. I can share my settings in the evening.

The only special case I have: my router is in a different room than the modem and I use vlan (tagged and untagged) to route the traffic over one connection back to my core switch in the basement.

First: I'm using an outdated version of OpenWRT (18.06.4) and planning to upgrade this weekend.

Here's my /etc/config/igmpproxy:

config igmpproxy
	option quickleave 1
#	option verbose [0-3](none, minimal[default], more, maximum)

config phyint
	option network wan
	option zone wan
	option direction upstream
###	list altnet 192.168.1.0/24
	list altnet 87.128.0.0/11
	list altnet 224.0.0.0/4
	list altnet 193.158.0.0/15
	list altnet 239.35.0.0/16

config phyint
	option network lan
	option zone lan
	option direction downstream
	list altnet 192.168.1.0/24

My /etc/config/network


config interface 'loopback'
	option ifname 'lo'
	option proto 'static'
	option ipaddr '127.0.0.1'
	option netmask '255.0.0.0'

config globals 'globals'
	option ula_prefix 'fdbc:33fb:8f21::/48'

config interface 'lan'
	option type 'bridge'
	option igmp_snooping '1'
	option ifname 'eth1.1'
	option proto 'static'
	option ipaddr '192.168.1.1'
	option netmask '255.255.255.0'
	option ip6assign '60'

config interface 'wan'
	option ifname 'eth0.7'
	option proto 'pppoe'
	option password 'xxx'
	option username 'xxx@t-online.de'
	option ipv6 'auto'

config interface 'wan6'
	option ifname 'eth0.7'
	option proto 'dhcpv6'

config switch
	option name 'switch0'
	option reset '1'
	option enable_vlan '1'
	option igmp_snooping '0'
	option igmp_v3 '0'

config switch_vlan
	option device 'switch0'
	option vlan '1'
	option vid '1'
	option ports '1 2 3 4 5 6t'

config switch_vlan
	option device 'switch0'
	option vlan '7'
	option vid '7'
	option ports '0t 5t'

My /etc/config/firewall:

config defaults
	option syn_flood '1'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'REJECT'

config zone
	option name 'lan'
	option input 'ACCEPT'
	option output 'ACCEPT'
	option forward 'ACCEPT'
	option mtu_fix '1'
	option network 'lan wg0'

config zone
	option name 'wan'
	option input 'REJECT'
	option output 'ACCEPT'
	option forward 'REJECT'
	option masq '1'
	option mtu_fix '1'
	option network 'wan wan6'

config forwarding
	option src 'lan'
	option dest 'wan'

config rule
	option name 'Allow-DHCP-Renew'
	option src 'wan'
	option proto 'udp'
	option dest_port '68'
	option target 'ACCEPT'
	option family 'ipv4'

config rule
	option name 'Allow-Ping'
	option src 'wan'
	option proto 'icmp'
	option icmp_type 'echo-request'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-IGMP'
	option src 'wan'
	option proto 'igmp'
	option family 'ipv4'
	option target 'ACCEPT'

config rule
	option name 'Allow-DHCPv6'
	option src 'wan'
	option proto 'udp'
	option src_ip 'fc00::/6'
	option dest_ip 'fc00::/6'
	option dest_port '546'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-MLD'
	option src 'wan'
	option proto 'icmp'
	option src_ip 'fe80::/10'
	list icmp_type '130/0'
	list icmp_type '131/0'
	list icmp_type '132/0'
	list icmp_type '143/0'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Input'
	option src 'wan'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	list icmp_type 'router-solicitation'
	list icmp_type 'neighbour-solicitation'
	list icmp_type 'router-advertisement'
	list icmp_type 'neighbour-advertisement'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-ICMPv6-Forward'
	option src 'wan'
	option dest '*'
	option proto 'icmp'
	list icmp_type 'echo-request'
	list icmp_type 'echo-reply'
	list icmp_type 'destination-unreachable'
	list icmp_type 'packet-too-big'
	list icmp_type 'time-exceeded'
	list icmp_type 'bad-header'
	list icmp_type 'unknown-header-type'
	option limit '1000/sec'
	option family 'ipv6'
	option target 'ACCEPT'

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config include
	option path '/etc/firewall.user'

config rule
	option target 'ACCEPT'
	option src 'wan'
	option name 'Allow-UPD-IPTV'
	option family 'ipv4'
	option proto 'udp'

config rule
	option src '*'
	option target 'ACCEPT'
	option proto 'udp'
	option dest_port '1234'
	option name 'Allow-Wireguard-Inbound'

Just ask if you need help.

@lleachii and @dlakelan maybe you can point me in the right direction of my initial post: Why my IGMP snooping in the switch config will break my igmpproxy (IPTV stops working)?

At the moment I don't use IGMP snooping or the IGMP v3 option in the switch config, which floods my switch on the Archer C2600. But normally nothing should be connected there. But I still want to know how to set it up correctly (for me and my family). Thanks in advance!

You're using a proxy, no snooping/non-snooping needed.

The purpose of the proxy is to move the multicast from WAN side to LAN side, the purpose of snooping in the bridge/switch is to keep ports that don't need multicast from receiving the multicast and clogging the pipes.

However multicast snooping is somewhat buggy in my experience on Linux/OpenWrt in general. In theory it should just work, in practice I find that it tends to work better in dedicated switches than on the kind of thing you get on all-in-one devices. It's not a feature that the typical consumer cares about so it's not really debugged in the consumer hardware.

@lleachii
Why I don't need a IGMP snooping when using igmpproxy? The switch in the Archer C2600 gets flooded when the IPTV box is in use. The IPTV box is connected to the TP-Link switch (T1600G-52TS) in the basement, which handles IGMP snooping. On the other hand the Archer C2600 is connected to port 2 of the T1600G-52TS (vlan 7 tagged and untagged). On port 1 of the T1600G-52TS is the VDSL2 modem with a vlan 7 tagged only. So I can use a PPPoE connection over vlan 7 and route the internet traffic to all untagged ports of the T1600G-52TS. Meanwhile the switch in the C2600 doesn't do IGMP snooping and causes package flooding to all its ports. How can I prevent this?

@dlakelan
That's the same understanding I have. I just wonder why multicast stops working on the IPTV box when IGMP snooping in the switch of the C2600 is enabled. Maybe I have to dig further with tcpdump.

I bet that the C2600 itself is not seeing the IGMP request from your LAN device that wants to hear the packets, therefore igmpproxy doesn't know you're subscribing, therefore it never sends a subscribe to the WAN side... that'd be my first guess. You could try disabling igmp snooping on the C2600 and then plug a decent consumer managed switch like a SG108e or a zyxel into the C2600 to provide a switch that does have debugged IGMP snooping.

That's my current setup. The core switch in the middle T1600G-52TS does IGMPv3 and IGMP snooping. I need to use igmpproxy on the C2600 to provide the multicast to my IPTV box.

The switch of the C2600 is in the same untagged vlan like the core switch. I haven't enabled IGMP snooping and IGMP v3 on the C2600 because than my IPTV box doesn't work. And that's also the reason why the switch in the C2600 floods all clients with multicast packets.

So you telling me the only solution is another switch connected to / after the C2600 to block the multicast? Than I would test to put all switchports on the C2600 into a separate vlan and route all traffic over the cpu of the C2600. That would be slower but should work.

Well, first what else is connected to the C2600? If there are additional devices hard wired into it that you are hoping not to spam with multicast... then yes, I suggest putting a cheap consumer managed switch between the C2600 and those devices

On the other hand, if everything that's hardwired can go into the T1600G and disconnect everything from the C2600 except the one link to the T1600G then you just enable snooping on the T1600G and everything should be fine.

But this is going to be VASTLY slower, like maybe 100Mbps instead of 1Gbps

Okay, thanks for mention that. At the moment there is only one development device (Rpi4) temporaly connected to the C2600. I just want to know all limitations.
I have to setup two different networks for my family and their don't have such a core router and have to connect some devices to the OpenWRT router itself. That's the use case.

Just for information. I found an old entry about the same question: https://openwrt-devel.openwrt.narkive.com/BXnHsjX0/about-igmp-snooping-support

Hi,

My router hardware has a AR8327 switch which is supposed to support hardware
IGMP snooping, but it seems it doesn't work on my OpenWrt of trunk.
I noted that in target/linux/generic/files/drivers/net/phy/ar8216.h there is
a AR8327_FWD_CTRL1_IGMP defined but not used anywhere.
And there is a config option CONFIG_BRIDGE_IGMP_SNOOPING in kernel config.
Does these two affect this feature? How can I enable IGMP snooping in
OpenWrt on my router

IGMP snooping for switches has a slightly different meaning than IGMP
snooing support in linux.
For switches (also for AR8xxx) IGMP snooping means that any
JOINS/LEAVES are redirected to the CPU port, so the CPU can
setup/update the appropriate forwarding entries in the switch.
So for this feature to work it requires a daemon capable of that,
which currently doesn't exist.

The IGMP snooping from linux does something like that already, but
only for bridge interface members. That means that is able to prevent
multicast traffic from leaking to wlan, but it does not have any
influence to the individual switch ports.

Jonas

So I guess there is no daemon available after 8 years.

I just read nearly every thread here in the forum about IGMP snooping. This is the most interesting one: Multicast/switch/snooping/vlan problem. Bug?

There is suggested to invert the CPU ports to the switch. I will try that and test IGMP snooping again. But first I will update today to the latest stable release.

Okay, I updated to the latest stable release (19.07.4) and tested following cases:

  1. Enable igmp snooping and igmpv3 in the switch config and leave everything like in the config posted earlier: the multicast stream on the iptv box stops after some seconds and stands still for about 4 seconds. After that time the streams works again for about 10 seconds. The network doesn't get flooded.
  2. I tested only igmp snooping without igmpv3 enabled: same results as in 1.
  3. Only igmpv3 without igmp snooping doesn't seem to have an effect: the stream works fine and my network gets flooded.
  4. I inverted the CPU ports in the network config. All eth0 interfaces changed to eth1 interfaces and vice versa. In the vlan section I inverted the CPU ports of the vlan 1 and vlan 7. After it I enabled igmp snooping and igmpv3. The stream on the iptv box stops after some seconds, then the sound disappears and the stream gets really stuttering and laggy without sound. This was the same result before I sysupgraded the router without changing the CPU ports. So the update in 1. is an improvment but still not usable. :frowning:
root@OpenWrt:~# tcpdump -n -i eth1.1 'igmp'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1.1, link-type EN10MB (Ethernet), capture size 262144 bytes
11:41:08.525609 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:41:15.944149 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:41:18.948919 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:41:18.976102 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:41:26.892805 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:41:34.252050 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:41:42.433037 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:41:49.573587 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:41:50.329828 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:41:53.334158 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:41:54.615809 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:42:03.930604 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:42:13.927021 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:42:22.977089 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:42:27.554219 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:42:27.896466 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:42:31.356943 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:42:37.353177 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:42:43.360470 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:42:52.774095 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:43:01.929970 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:43:08.577036 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:43:14.586791 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:43:16.777194 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:43:23.065380 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:43:26.069681 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:43:39.130970 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:43:50.426970 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:43:57.850931 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:43:57.850931 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:44:04.064552 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:44:07.069125 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:44:07.116864 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:44:16.048199 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:44:19.052332 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:44:25.930322 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:44:37.375559 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:44:45.292651 IP 192.168.1.1 > 224.0.0.1: igmp query v2
11:44:51.119662 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
11:44:51.119662 IP 192.168.1.195 > 232.0.20.85: igmp v2 report 232.0.20.85
^C
38 packets captured
41 packets received by filter
0 packets dropped by kernel
root@OpenWrt:~#

With igmp snooping on the latest version of OpenWRT I can see igmp traffic on the interface, but the iptv box stops the stream periodically after some seconds and starts it again.