What's new

does IGMP proxy/multicast routing with no ISP profile assist igmp snooping on managed switches

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Pierre Nakashian

Regular Contributor
I have 3 devices 2 raspberry pies running home assistant, and I suspect Amazon FireTV recast
are blasting my home network with multicast traffic. I did have an unmanaged switch in the middle
the home is prewired into a panel, needed something there to connect all the home lan wiring to one
switch, which then could connect to the RT-AX88u with 1 wire. I have a hunch the unmanaged switch was also a catalyst to the problem.

They have brought my network down many times,
running
/sbin/service stop_mdns

on the access point routers where these 3 devices are connected to restores my network,
but i don't like to leave that feature off, it doesn't really fix/address the issue,
Home assistant can't find some devices to automate if its left off.

I've google alot on IGMP proxy/IGMP snooping. so I finally gave in and purchased affordable managed switches
that I could turn on IGMP snooping. with the 3 suspect devices now connected to the managed switches instead.
before I setup the managed switches i had configured IGMP proxy on rt-ax88u for about a week and forgotten about it.
googling says it supposed to work with upstream interface to the ISP devices such as IPTV, which I don't have one,
i own streaming devices FireTV cube. but I didn't choose any upstream ISP profile see image below.
1666328763820.png


the Home assistants devices and Firetv recast do receive internet traffic, For Home Assistant I have special
rules setup on RT-AX88u to allow outside traffic originating at AWS to reach them the 2 home assistants, using only 1 port 443, sslh, stunnel and unique sni hostname
from freeddns.org

I suspect the Firetv Recast is also using multicast traffic to all the FireTV cubes i have setup on my lan,
just a hunch there is constant multicast traffic to create video thumbnail on fireTV cubes, and guide data as well.

with my new managed switches installed/setup, Every time i disable "Enable multicast routing/IGMP Proxy" on my RT-AX88u my network goes down.

So does a managed switch with igmp snooping need or function better with
IGMP Proxy/multicast routing turned on my main router only even the way i configured it?

Full disclover I am using on RT-AX88u LAN-> Switch Control->Bonding/ Link aggregation->Lan1+Lan2 to the managed switch Ling Aggregation 2 ports.
also have Dual Wan with Load balance using my own scripts to make sure the 2nd ISP WAN is restarted on reboots when it doesn't come up.
 
With multicast, a switch normally operates like a hub, it is essentially broadcast traffic and is sent out all ports. IGMP snooping allows the switch to look into the multicast packet, determine which ports need it, and stop it from being sent to the ports that don't need it. Unless you have a ton of multicast data, it probably isn't going to help a whole lot. If you've got 1G wired devices and 20 megs of multicast, not a big deal. Can't hurt to reduce the wasted bandwidth, but I don't think it is going to solve your problem.

Any port that is requesting multicast data will continue to receive it. If those 3 suspect devices are sending/receiving multicast, then IGMP snooping will not affect their ports at all. If the destination of that traffic is the Asus router, then its port will continue receiving that traffic also. IGMP snooping won't kick in on any of those ports.

To stop multicast traffic you need to look at the suspect devices or the Layer 3 device (the Asus). When you say your network goes down, is it the wired network, wireless, both? On wired, hard to see how you would be sending a gig of multicast traffic, that's a whole lot of video. On wireless, it would still take a lot to saturate the link.

The IPTV settings on the Asus are more for routing WAN multicast to the LAN, but you said you don't have IPTV from the WAN. I guess some features there may also impact the LAN handling of multicast but if it is all local multicast traffic, then the router doesn't really come into play at all. The exception is if you are doing multicast between wired and wireless (or two different wireless interfaces), it does pass through the bridge interfaces on the Asus, and not sure if that would be processed by software or hardware. Also, if those devices are attempting to send multicast to the internet or something outside of your LAN (which wouldn't work regardless) then it would fall on the router to process and drop it all, maybe that is spiking the CPU and locking it up? Are you able to access the GUI during these "outages" to check the CPU?

You may want to have a look at the WMM and Multicast settings under the wifi advanced in the Asus, maybe something there is causing issues. I highly doubt the FireTV is using very much bandwidth at all, if it is in fact using multicast, that's a good thing, it is reducing the amount of bandwidth being used in total. Maybe put yourself into the "outage" situation and start unplugging devices, when the issue stops, you know which device(s) to focus on.
 
"does IGMP proxy/multicast routing with no ISP profile assist igmp snooping on managed switches"

No.
 
Thanks for taking the time to respond.

People reporting Home assistant multicast issue, described it as multicast feedback loop bug, in another forum.

the image below shows multicast spikes from 25Bytes/sec to suddenly 400Bytes/s one of those coincides
with 8769 context switches/sec in the graph below my network did not go down. In the past when I was able to capture Multicast bytes/s with internet outage I've seen it as high as 500-1000bytes/sec. Mcast data is measured sum across all interfaces inside the rt-ax88u from /proc/net/dev. I also don't know if multicast is converted to Broadcast/unicast traffic after this increase. My measurements could still be low by not taking those traffic sizes into account.

1666347376760.png


The last time only my 1GBit LAN devices went down because some of my managed switches went down and some were strangely slow to access from wifi. My notebook was still able connect to RT-AX88U directly via 5g wifi and it still had internet access. But my notebook couldn't access some of the managed switch devices via web interface, unplugging them, then plugging them back gave me brief access before they went down again, I eventually turned on "Enable Multicast routing" and then unplugging/plugging back the managed switches came back. then some IOT lan devices still didn't recover, i had to unplug/replug them as well.

In the past before my managed switches, wifi and lan devices lost internet access, i had to ssh to each access point
and run /sbin/service stop_mdns to recover internet.

My old unmanaged switch did not have any IGMP snooping (i don't know if some do), so traffic from Home assistant would go there, go to one of the other ports where my other Access point was connected to then come back, then go to another port to another access point and come back and 2 Home assistant hardware itself are behind another single access point rt-ac68u. After sustained multicast consumption of 1000Bytes/sec is where I noticed loss of internet.
I don't know if my old switch prevented loops here before reaching RT-AX88u. all my routers RT-AX88u and RT-ac68u do have Spanning-Tree Protocol turned on.

Today
I again set Lan->IPTV->"Enable multicast routing" to disabled without reboot, instantly all my FireTv are complaining no internet access, no difference if I connected them to my rt-ac68u access point routers, or the new managed switches.
my apple tv internet access didn't go down. I ssh inside the rt-ac68u access point and pinged external site, it still had internet access.

This time my managed switches didn't go down, Before today I did carefully configure one extra suspect device (Amazon FireTV Recast) connected directly to the managed switched for storm control for broadcast/multicast/UL-Frame packets limiting now the 3 devices to 64Kbit/sec max broadcast traffic.
I rebooted the RT-AX88u and left "Enable multicast routing" disabled, my fireTV regained internet access again.

I can only conclude changing that setting requires I reboot the RT-AX88u, my RT-AX88U lan ports didn't communicate well to the 1st managed switch. I did have RT-AX88u LAN-> Switch Control->Bonding/ Link aggregation->Lan1+Lan2 to the managed switch Ling Aggregation 2 ports, that feature must not have run properly after multicast routing was disabled.
I may have to take note and reboot the router now more often after changing settings.

The multicast traffic before my new managed switches with storm control, affected my wifi calling also, every 5-10 seconds people couldn't hear my audio. I don't think its a bandwidth issue with the RT-AX88u, but maybe some cache/queue size set aside used for multicast/broadcast traffic is not high enough, if a few devices abuse multicast traffic and consume close to the overall quota in RT-AX88u. Managed switch without storm control did not address this issue.

Strangely some network traffic also affects FireTV Cube 100mbit interface to streaming 4k video content, every 10sec it would buffer or drop resolution from 4k to 1080hd, and I have 1Gbit internet access, even with my managed switches with storm control. However using robocfg, vconfig, ifconfig, brctl commands (no ebtables) I created a vlan vlan14 isolating port 4 on rt-ac68u access point, then FireTV cube can play 4k content without buffering or resolution drops.
i can only conclude network buffer size on fireTV cube 100mbit interface is set too small, and any lan traffic will steal the small buffer away from streaming 4k content. Apple tv with 1gbit interface didn't have any issues no matter where it's connected.

my 5g wifi settings are
1666348639070.png


my 2.4ghz wifi settings are
1666348712325.png
 
you only need one switch per subnet to enable IMGP snooping, whether it's the switch in the router itself, or downstream to a L2/L3 managed switch.

IPTV support is mostly about carrier provided services (e.g. triple play, broadband, internet, and perhaps dial tone) and handling the VLAN associations.

Multicast to Unicast translation on the WLAN side - this can break a lot of client implementation, mostly because WiFi is a bit stupid here on the client side, so enabling IGPM items here can cause breakage as noted.
 
Thanks for taking the time to respond.

People reporting Home assistant multicast issue, described it as multicast feedback loop bug, in another forum.

Sounds like a broadcast storm (multicast is just a type of broadcast UDP), which can certainly saturate not only bandwidth but CPUs. The symptoms you're describing are similar to a spanning tree loop too though, make sure you don't have anything that might be causing that. Either one can take down a network. The fix is going to be fixing the device with the issue (or disconnecting it until it is resolved), not trying to use features on a router/switch. Any feature that will stop that issue will prevent the device from working correctly anyway (as you've noticed with discovery not working etc) and just tax the device to block and drop all that rogue traffic.
 
you only need one switch per subnet to enable IMGP snooping, whether it's the switch in the router itself, or downstream to a L2/L3 managed switch.

IPTV support is mostly about carrier provided services (e.g. triple play, broadband, internet, and perhaps dial tone) and handling the VLAN associations.

Multicast to Unicast translation on the WLAN side - this can break a lot of client implementation, mostly because WiFi is a bit stupid here on the client side, so enabling IGPM items here can cause breakage as noted.

on the RX-AX88u there is no IGMP snooping option to enable in the gui,
and when I try to enable via nvram set emf_enable=1 on next reboot it changes back to 0
I thought if I disabled IGMP proxy this behavior would change but it didn't.

IGMP proxy wasn't suppose to do anything helpful in my situation, but after I disabled it and rebooted the router
my multicast traffic went down coincidently. I turned it off 7am, and it flatlined to 27 max. I still have igmp snooping on
and storm control on each managed switch.

1666400210871.png


which setting in my wifi profession settings is >>Multicast to Unicast translation on the WLAN side
is this the same setting as IGMP snooping for wifi?
 
Sounds like a broadcast storm (multicast is just a type of broadcast UDP), which can certainly saturate not only bandwidth but CPUs. The symptoms you're describing are similar to a spanning tree loop too though, make sure you don't have anything that might be causing that. Either one can take down a network. The fix is going to be fixing the device with the issue (or disconnecting it until it is resolved), not trying to use features on a router/switch. Any feature that will stop that issue will prevent the device from working correctly anyway (as you've noticed with discovery not working etc) and just tax the device to block and drop all that rogue traffic.
When I see multicast climb up it shows up only 1000bytes/sec but at the same time my data capture shows high context switches. Maybe in my case is very high Context switches that brings my rt-ax88u.

Spanning tree loop, I have feeling with my old unmanaged switch in between RT-AX88u and multiple rt-ac68u was causing that. RT-AX88u and RT-ac68u already had the STP turned on, but the unmanaged switch in between didn't have that feature. My new managed switch has Loop Prevention Setting which sound similar to Spanning tree loop prevention
so cross my finger I have no place left for STP loop.

I've been having that broadcast storm off and on, they had a fix in the middle, but then it came back.
using rt-ac68u vlan utilities with ebtables to block most traffic out of the Home assistant worked for some time, but as you mentioned it could no longer detect new devices that well anymore. I'm still research/converting from Home assistant to Hubitat. It takes time, it doesn't have all the feature i can migrate and reprogram.
 
When I see multicast climb up it shows up only 1000bytes/sec but at the same time my data capture shows high context switches. Maybe in my case is very high Context switches that brings my rt-ax88u.

Spanning tree loop, I have feeling with my old unmanaged switch in between RT-AX88u and multiple rt-ac68u was causing that. RT-AX88u and RT-ac68u already had the STP turned on, but the unmanaged switch in between didn't have that feature. My new managed switch has Loop Prevention Setting which sound similar to Spanning tree loop prevention
so cross my finger I have no place left for STP loop.

I've been having that broadcast storm off and on, they had a fix in the middle, but then it came back.
using rt-ac68u vlan utilities with ebtables to block most traffic out of the Home assistant worked for some time, but as you mentioned it could no longer detect new devices that well anymore. I'm still research/converting from Home assistant to Hubitat. It takes time, it doesn't have all the feature i can migrate and reprogram.

As long as each one was only connected to the switch once and not to each other, there should not have been any loops. It is possible somehow you had bridged them wirelessly in addition to wired, but unlikely, and that wouldn't necessarily create a loop, it depends on the architecture between the wired and wireless interfaces. Definitely sounds like this rogue broadcast/multicast traffic is the culprit. Something is getting bogged down trying to deal with or drop it.

Storm control and loop prevention/STP are things that are there to prevent accidents or unlikely events, not things that should be kicking in all the time or used to prevent something known.

As you say, even though bandwidth wasn't necessarily saturated, these routers are not designed for a lot of multicast, most likely it is processed at least somewhat in software which is why you're seeing a high amount of CPU calls. Even if it doesn't drive the CPU to 100% there are ASICs, wifi controller, etc in there too that can be impacted. Packets per second can have just as much impact as bits per second too, maybe they are very small packets but a ton of them.

Unfortunately this probably isn't something you're going to be able to solve with your Asus router other than blocking the traffic completely and losing the functionality associated.
 
I used to have three FireTV sticks, no home assistant or raspberry pies. Those FireTV sticks spammed my LAN with an ungodly amount of mdns packets and slowed everything to a crawl, overwhelming everything. I can't remember what the actual number was but I used Wireshark to verify my suspicions. Replaced them with Rokus, problem solved. Rokus don't use multicast.
 
I used to have three FireTV sticks, no home assistant or raspberry pies. Those FireTV sticks spammed my LAN with an ungodly amount of mdns packets and slowed everything to a crawl, overwhelming everything. I can't remember what the actual number was but I used Wireshark to verify my suspicions. Replaced them with Rokus, problem solved. Rokus don't use multicast.
yup you're right, every amazon product is flooding my network,
firestick, firetv cube, echo show, firetv recast are flooding mdns.

using wireshark capture "ip.addr eq 224.0.0.0/24" ipv4 statistics source and destination addresses
top 5
-----
Home assistant 15%,
1st gen firetv cube 7%,
echo show 8 6.5%,
firetv recast 6.5%,
echo show 5 6.4%
 
Last edited:
it looks like Home Assistant in raspberry pie besides sending MDNS packets it was causing all the amazon devices to send MDNS packets continuously as the other user mentioned. Home Assistant reached 30% of MDNS traffic.
i put this command in the raspberry pi, putting it on the main interface eth0 didn't do anything for some reason
so i applied the command on all interfaces.

/usr/sbin/ebtables -A FORWARD --pkttype-type multicast -j DROP

after that Home Assistant dropped to 2nd highest MDNS traffic,
firetv cube now is the 6th highest MDNS traffic down from 2nd.

also noticed Asus RT-AX88u sending IGMP query every 20seconds, per /var/mcpd.conf configuration file.
I don't know if there is a correlation to IGMP query and follow-up MDNS traffic
but I do see MDNS query responses, and IGMPv2 membership report to the IGMP query
I changed the interval to 120seconds in /var/mcpd.conf killed mcpd process and restarted it.
The other post in this forum of putting this file /jffs/scripts/mcpd.postconf didn't seem to work,
the 20 second interval stayed 20seconds.
now IGMPV3 query runs every 120seconds.

I'll be paying attention on wireshark off and on, and the other automated graph I generate to see total MDNS traffic.

total mdns traffic was reaching 154bytes/sec today, now its finally leveled to 16bytes/sec.
the peaks coincide when media was being streamed, and leveled off when no one was streaming.
now with streaming it still is remaining at 16bytes/sec level.
cross my fingers hope this is the end of cascade MDNS traffic between home assistant and mostly amazon devices.
1666486223904.png
 
Last edited:
it looks like Home Assistant in raspberry pie besides sending MDNS packets it was causing all the amazon devices to send MDNS packets continuously as the other user mentioned. Home Assistant reached 30% of MDNS traffic.

Multicast DNS is not an efficient protocol, but one device being 30% of it doesn't mean anything. If there are 10 requests per hour and one device is 3 of them, that's fine. If it's 10 billion per hour that's a problem.

And yes, one device sending MDNS packets will result in all other devices that support it also sending packets. That's by design. Unfortunately it also means one device with issues can wreak havoc even if all your other devices are acting correctly.

Sounds like your raspberry pi is attempting to discover way too frequently and causing a lot of excess multicast traffic from the various other devices that support it.

Even though this traffic never leaves the LAN the Asus will see it and have to decide what to do with it since it is multicast enabled. If one/some of those devices are wired and one/some are wireless (or if using two different wireless frequencies, or a mix of regular and guest wireless SSIDs), that's even more load on your Asus (plus multicast over wifi can be problematic anyway).

You shouldn't need to mess with IGMP timings on the router, that's not going to change anything with those devices that are utilizing MDNS.

Out of curiosity are any of the devices using guest wireless 1?
 
Multicast DNS is not an efficient protocol, but one device being 30% of it doesn't mean anything. If there are 10 requests per hour and one device is 3 of them, that's fine. If it's 10 billion per hour that's a problem.

And yes, one device sending MDNS packets will result in all other devices that support it also sending packets. That's by design. Unfortunately it also means one device with issues can wreak havoc even if all your other devices are acting correctly.

Sounds like your raspberry pi is attempting to discover way too frequently and causing a lot of excess multicast traffic from the various other devices that support it.

Even though this traffic never leaves the LAN the Asus will see it and have to decide what to do with it since it is multicast enabled. If one/some of those devices are wired and one/some are wireless (or if using two different wireless frequencies, or a mix of regular and guest wireless SSIDs), that's even more load on your Asus (plus multicast over wifi can be problematic anyway).

You shouldn't need to mess with IGMP timings on the router, that's not going to change anything with those devices that are utilizing MDNS.

Out of curiosity are any of the devices using guest wireless 1?
The 30% i described was when all amazon devices pretty much responding to mdns every second and multiple times per second. wireshark never had an idle moment. Now mdns traffic has idle moments, and in terms of bytes 90% less bytes.

I don't have guest network setup, so FireTV Cubes are wired, FireStick, echo show, and echo dots are wireless, some are on 2.4Ghz due to intermittent network drops, some are using 5Ghz.
I can audit which devices are on 2.4Ghz and switch all of them to 5Ghz again. It could be what I thought was a 2.4Ghz, 5Ghz wifi issue, was a mild mdns storm issue overloading the router and dropping wifi connection as an end result. I have been perplexed with intermittent wifi drops by my devices, followed best practices from this forum but never eliminated mysterious wifi drops.

If the ebtable inside the Home Assistant raspberry pie doesn't hold up, I have a feeling it is the Alexa Media Player integration that is behind this issue. Home Automation maybe cool, but not if controlling Alexa speaking devices is
going to cause excessive polling of Amazon devices.

Now that I know the storm is exclusively between Home Assistant to Amazon devices, I'll also turn off these 2 options in Home Assistant Alexa Media Player integration, and see what functions I loose and if the MDNS lowers even more and whether I still need to run the ebtables command in the raspberry pie. Maybe these 2 options are utilizing MDNS and unfortunately Home Assistant does not have an option what interval the polling should be done.

1666536886103.png


I'll revert my IGMP query interval changes.

Thanks for the feedback.
 
I don't have guest network setup, so FireTV Cubes are wired, FireStick, echo show, and echo dots are wireless, some are on 2.4Ghz due to intermittent network drops, some are using 5Ghz.
I can audit which devices are on 2.4Ghz and switch all of them to 5Ghz again. It could be what I thought was a 2.4Ghz, 5Ghz wifi issue, was a mild mdns storm issue overloading the router and dropping wifi connection as an end result. I have been perplexed with intermittent wifi drops by my devices, followed best practices from this forum but never eliminated mysterious wifi drops.

Multicast over wireless has it's own set of challenges. Typically it is fine but these home routers aren't optimized for lots of multicast queries and responses, more designed for constant streaming, and even that isn't very common.

Under advanced wireless settings you can try toying with stuff like multicast rate etc but I have a feeling if you have lots of traffic being processed between wired, 2.4, and 5.0 it may just be overloading an ASIC or portion of the CPU, or even if not overloading it just slowing it down. Or simply packets getting buffered waiting to be processed, and your normal traffic gets stuck behind that.

MDNS is almost like broadcast, devices attempting to keep track of each other without a central device. Multiple times per second certainly seems like something is malfunctioning. While the traffic can sometimes be excessive, that seems really abnormal.

Good luck on it but seems like you've narrowed down the device causing the issue so at least you know where to focus.
 
Last time I set IGMPv3 and fast leave on my devices in the house over Wired LAN would randomly disconnect. Disabled fast leave and everything worked fine. Just figured I’d share that incase fast leave is causing issues.
 
Multicast over wireless has it's own set of challenges. Typically it is fine but these home routers aren't optimized for lots of multicast queries and responses, more designed for constant streaming, and even that isn't very common.

Under advanced wireless settings you can try toying with stuff like multicast rate etc but I have a feeling if you have lots of traffic being processed between wired, 2.4, and 5.0 it may just be overloading an ASIC or portion of the CPU, or even if not overloading it just slowing it down. Or simply packets getting buffered waiting to be processed, and your normal traffic gets stuck behind that.

MDNS is almost like broadcast, devices attempting to keep track of each other without a central device. Multiple times per second certainly seems like something is malfunctioning. While the traffic can sometimes be excessive, that seems really abnormal.

Good luck on it but seems like you've narrowed down the device causing the issue so at least you know where to focus.

Even after I disabled Home Assistant to not communicate with Amazon devices, after I went around and changed the WIFI to the 5Ghz band consistent on all, it woke them up right away, they started just storming low/medium level mdns traffic upto 250Bytes/sec, on my router 1000Bytes/sec is fatal. Amazon uses alot of multicast for regular network activity. Top 10 devices with MDNS traffic again were Amazon devices now.

I was running out of time to investigate this weekend, as Proof of Concept i wanted to see if i could block
multicast traffic on RT-AX88u.
i ran commands like below for most of my Amazon devices by their mac address.
Wireshark still captured MDNS replies from these amazon devices, but my graph over time showed some of the commands below were working in reducing traffic, or i got lucky they finally went idle.
1666588287648.png

If I was behind MDNS traffic reduction that i can say we can't block 100% MDNS but we can reduce it, maybe if its related to the IGMP query it can't be dropped. otherwise it was a coincidence traffic leveled down.
I did try to target by wifi interface eth6,eth7 again wireshark didn't see 100% mdn packet drop on amazon devices so its a long day to test.

i'll have to figure out which of these were the useful ones later.

iptables -I FORWARD -m mac --mac-source $AMZ_MAC -d 224.0.0.251 -p udp --dport=5353 -j DROP
iptables -I OUTPUT -m mac --mac-source $AMZ_MAC -d 224.0.0.251 -p udp --dport=5353 -j DROP
iptables -t mangle -I FORWARD -m mac --mac-source $AMZ_MAC -d 224.0.0.251 -p udp --dport=5353 -j DROP
iptables -t raw -I OUTPUT -m mac --mac-source $AMZ_MAC -d 224.0.0.251 -p udp --dport=5353 -j DROP
ebtables -I FORWARD -s $AMZ_MAC --pkttype-type multicast -j DROP
ebtables -I OUTPUT -s $AMZ_MAC --pkttype-type multicast -j DROP

With the MDNS packet drops fire TV cube does seem to be missing TV media thumbnails on channels but it downloads it within 5 seconds after going to home menu. one of the Echo show stopped displaying the clock, it had to be rebooted to fix that. So they don't like MDNS packets being blocked.

lesson learned don't buy too many amazon devices. I'll have to try the RT-AX88u block internet device in GUI next week, to block devices i'm not using that much.
Network Map->Client->Client Status->device->Block Internet Access.

I may have to experiment special guest wireless network for the wireless amazon devices, and modified iptables/ebtables command when leaving the guest network interface. sort of creating a smaller vlan, with RT-AX88u that is not quite possible like it was with RT-AC68u. it doesn't have robocfg command. I know some of the amazon devices are looking for each other, in an ideal solution i would put wired/wireless amazon devices in the same vlan away from the rest of my devices

but i now the know devices i have to quarantine one way or another.
 
Last edited:
Last time I set IGMPv3 and fast leave on my devices in the house over Wired LAN would randomly disconnect. Disabled fast leave and everything worked fine. Just figured I’d share that incase fast leave is causing issues.
that screen is for IPTV. i have that turned off, not sure if it affects me
i do see in file /var/mcpd.conf
igmp-fast-leave 1

maybe my rt-ax88u igmp query uses that setting, not sure.
I have the random disconnects with WIFI devices not wired.
if I see in the future random wifi disconnects I'll experiment on that setting in the file.
 
Even after I disabled Home Assistant to not communicate with Amazon devices, after I went around and changed the WIFI to the 5Ghz band consistent on all, it woke them up right away, they started just storming low/medium level mdns traffic upto 250Bytes/sec, on my router 1000Bytes/sec is fatal. Amazon uses alot of multicast for regular network activity. Top 10 devices with MDNS traffic again were Amazon devices now.

1kbyte/sec of multicast traffic is nothing. However if that is made up of thousands of tiny MDNS packets, I suppose it could be an issue, but even at the smallest possible packet sizes that is only 15 per second. Are you sure you're capturing all the traffic? Not sure where you're sniffing. There have been bugs reported with several devices and brands where when the device is on but disconnected, it queues up all the MDNS queries then floods them out, but those should have been mostly resolved by now, but maybe home assistant has a similar bug.

Also at this point under IPTV settings do you have everything disabled? You don't want to be routing multicast from LAN to WAN, that will not do anything for you and will just tax the router trying to route that multicast traffic into a black hole. If you aren't using IPTV from your ISP everything on that screen should be "none" "disable" and "0" for proxy. You can leave DHCP routes at microsoft, as long as multicast routing is disabled that doesn't take effect, or at least it shouldn't, but also shouldn't hurt to disable that too. You may need to do a full reboot after disabling all that, maybe let it sit for 5 minutes so all your multicast aware devices realize they are disconnected and clear their MDNS cache.

You could try leaving IGMP snooping enabled on that screen. This would potentially filter the MDNS queries from being sent to hardwired devices that are not multicast enabled, but the traffic should be negligible. Since most devices do now support multicast and MDNS, it probably will have little or no effect. Guess it can't hurt to try.

You can enable IGMP snooping on your wireless channels but again, that may have little or no effect on MDNS, but shouldn't hurt. You could try changing the multicast rate from Auto to something else, maybe it is throttling it to something very low.

Could also try disabling WMM, while not multicast related it does perform some throttling of certain traffic types on wireless and could potentially be compounding the problem.

Make sure airtime fairness is disabled on both bands also.

Out of curiosity, have you tried a factory reset - if you've been doing dirty upgrades of firmware it's possible something just isn't working right.

I suppose the Asus may just not be good with multicast however that would be strange - ever since Apple introduced Bonjour years ago multicast and MDNS have become very common in home networks. Windows and Linux both use it now too and I believe Android does too. Home routers have supported this for years now.
 
the kbytes /sec is not from sniffing, it is running this script on rt-ax88u every 5 minutes, then retrieving and
graphing it on Home Assistant.
its burst of 1000bytes/sec seem to coincide with severe network issues.
the 9th column of /proc/net/dev is labeled multicast. I sum it across all interfaces whose name start with eth.
only interfaces i'm not summing up that have non-zero value are bcmsw, bond0.
maybe i should be including one of them to get accurate multicast byte data.
This field gives me total bytes, I take the byte difference between
2 measurements divided by the time difference in seconds of the 2 measurements which is 300seconds.

cat /proc/net/dev | awk '{ printf("%s %s\n",$1,$9); };' |grep eth | awk '{s+=$2} END {printf("%s\n",s);}'

I have everything disabled in IPTV, on my rt-ax88u i don't have a screen from IGMP snooping for LAN devices
1666611778205.png


i have airtime fairness disabled, on 2.4/5ghz wifi igmp snooping enabled, my multicast rate is set at OFDM 36.
I figured 36 which I believe means 36Mbps is a good value for wifi calling, and possible video conference calls by Microsoft Teams app on my mobile device. I have terrible Cell reception in my house, wifi call is essential.
i can't disable WMM, the menu dropdown won't let me, it only has "enable" if you click on it.
I have rebooted RT-AX88u several times already when I disabled earlier part of this thread the router didn't behave properly after disabling Multicast Routing.
after reboot it worked.

I did not factory reset the last 2 FW updates, but I have the one before those 2.
after i put all the iptables/ebtable rules on amazon devices only, wireshark i finally do see iphone make mdns traffic, its not as bad as amazon devices.
I'm starting to believe its not the router fault, but too many amazon devices. Home Assistant definitely aggravated the amazon echo system like kicking a hornets nest.
i can try another factory reset next weekend and re-customize all the screens again, i have documented most of the custom changes, so that i don't restore settings after factory reset.
 
Last edited:

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top