Multicast container causing feedback loops

[jesserockz]

Since getting up this morning, devices on my network could not get an IP address.
I notice on my server that hassio_supervisor and hassio_multicast were created 8 hours ago.

Looking at my router there was a constant TX rate of about 8Mbps to my IoT and Guest vlans coming from my lan vlan.

No device on my network could get a DHCP reservation unless I stopped the hassio_multicast container which also halted the extra traffic transferring between the vlans.

Of course hassio_supervisor just starts the multicast container back up again and the issue is back.

I have had to tag a local dummy empty docker image with homeassistant/amd64-hassio-multicast:2 to resolve this for now.

[pvizeli]

I can't reproduce that issue. Maybe you have also other mdns repeater running and end up in a loop?

You can use ha multicast logs to track issue from where the traffics is comming. Our CoreDNS plugin just ask every 2 minutes with a handfull packages on the multicast address for devices.

[frenck]

I've checked this as well and cannot see this in my network (using multiple VLANs and additional repeaters between those as well).

[jesserockz]

From ha multicast logs
Screen recording

Repeating over and over again

data from=10.5.5.1 size=38
repeating data to enp5s0
repeating data to hassio
data from=10.2.2.1 size=38
repeating data to enp5s0
repeating data to hassio

[jesserockz]

Looks also like supervisor recreated the container with the original image this morning.
I found all of my IoT devices offline because they could not get an IP address lease again.

[pvizeli]

You should check this IP address. This plugin does not more than just copy the multicast broadcast for mDNS over to the hassio network. Also, DHCP is working on Broadcast, not Multicast. That is a pretty common process that is used on many firewalls/gateways.

You need to fix your Network issue or just run Home Assistant Core. The Supervisor will still try to fix the plugin every time. It could be also a Kernel issue on the system in which you run the Supervisor. Give us more details about your host.

[jesserockz]

Those IP addresses are the adapters on the router, 10.5.5.1 for IoT network, 10.2.2.1 for Guest.
Should it be repeating to enp5s0 then? Which is my host ethernet port.

Router is Ubiquiti Edgerouter X

Host info:

$ uname -a
Linux feijoa 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux

$ ip r
default via 10.1.1.1 dev enp5s0
10.1.1.0/24 dev enp5s0 proto kernel scope link src 10.1.1.44
10.2.2.0/24 dev enp5s0.2 proto kernel scope link src 10.2.2.44
10.5.5.0/24 dev enp5s0.5 proto kernel scope link src 10.5.5.44
10.100.100.0/24 dev zt0 proto kernel scope link src 10.100.100.44
169.254.0.0/16 dev enp5s0 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1
172.18.0.0/16 dev br-1a6738faed7e proto kernel scope link src 172.18.0.1
172.30.32.0/23 dev hassio proto kernel scope link src 172.30.32.1                                                                                             

Let me know if you want any specific details. Thanks for helping.

[jesserockz]

Ok, so just checked my router, it has an mdns repeater as well turn on for my vlans. If I turn it off I can start up the multicast container and everything is fine. But this is not a solution. I now will not have mdns across my vlans.

I think its definitely gotten into a loop with this mdns-repeater but like you mentioned, this one should only be repeating the data into the hassio network, but it is clearly sending it back out to the vlan.

[mattburchett]

Multicast is also getting stuck in a loop against mdns-repeater in my network (separated LAN, IOT network, and guest VLAN), causing issues with my network as a whole.

data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=90
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio

This docker log is also running my server out of space by how fast it's flowing.

if relevant, mdns-repeater is running of a Ubiquiti EdgeRouter X.

[jesserockz]

Multicast is also getting stuck in a loop against mdns-repeater in my network (separated LAN, IOT network, and guest VLAN), causing issues with my network as a whole.

data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=90
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio
data from=10.10.1.1 size=75
repeating data to eth0
repeating data to hassio

This docker log is also running my server out of space by how fast it's flowing.

if relevant, mdns-repeater is running of a Ubiquiti EdgeRouter X.

So exact same situation and setup as I have. I disabled the repeater on the router for now as we don't have control of which services the supervisor runs.

[kernehed]

I had the same issue as you. I did a dirty downgrade. But now when i'm trying to update HA it gives me errors:
20-04-22 10:42:03 INFO (MainThread) [supervisor.plugins.multicast] Start Multicast plugin 20-04-22 10:42:03 ERROR (SyncWorker_13) [supervisor.docker] Can't create container from hassio_multicast: 404 Client Error: Not Found ("No such image: homeassistant/amd64-hassio-multicast:2") 20-04-22 10:42:03 ERROR (MainThread) [supervisor.plugins.multicast] Can't start Multicast plugi 20-04-22 10:42:19 ERROR (SyncWorker_10) [supervisor.docker.interface] Can't install homeassistant/qemux86-64-homeassistant:0.108.7 -> 500 Server Error: Internal Server Error ("Get https://registry-1.docker.io/v2/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)"). 20-04-22 10:42:19 WARNING (MainThread) [supervisor.homeassistant] Update Home Assistant image fails

Edit: Managed to fix the error of multicast plugin with a reinstall of supervisor. Now my network is slow again and the plugin eats up my diskspace.

[shexbeer]

Same issue as you guys. Deleting this log every second day, but my 32 gig sd card is full after 24 hours again at least. Running similar network configuration. Very annoying currently.
Its also eating up a alot of ressources on the machine. Like avahi-daemon and mdns-repeater are going nuts

If multicast would be casting not only from wlan0/eth0 to hassio

repeating data to wlan0
repeating data to hassio

but instead do multicast between eth0 wlan0 and hassio, that would be awesome.
So i wouldnt need my own solution and therefor dont have the issues i have currently with that hassio mulitcast setup
Or let me disable your mdns-repeater ;)

[cyr-ius]

Same issue.

[kernehed]

When I downgrade to multicast_hassio:1 my network works as usual.
Is it somehow possible to have it downgraded without the wathcdog goes bananas?

After the downgrade I can't update HA or Supervisor.

This is the log. I have Mikrotik router and Unifi APs.
Installed in docker on Ubuntu 18.04.

data from=192.168.2.200 size=167
repeating data to ens160
repeating data to hassio
data from=192.168.2.200 size=110
repeating data to ens160
repeating data to hassio

[jslove]

Same issue for me, using unifi gateway and switches with multiple vlans

Edit:
I’m not seeing a DHCP issue, my problem is the massive logfiles filling up my drive. I’m getting 500M/hour in the log. I have had to soft link the container’s log to /dev/null.

[jesserockz]

I have been looking into the mdns-repeater that you are using.
For configuration you specify 2 interfaces, in my case enp5s0 and hassio. But the server listens on every interface on the host machine, and repeats everything coming in on any interface out to the specified interfaces.

Options maybe:

• Allow the users to disable this plugin
• Allow configuration of the -b blacklist parameters to allow the users to tell mdns-repeater to ignore the other vlan packets if they are already being repeated to the main interface (below)
• Update mdns-repeater to only listen on the specified interfaces
• Find/write a new repeater

I turned on my router mdns-repeater and ran the multicast container with a bash entrypoint then ran mdns-repeater -f -b 10.2.2.0/24 -b 10.5.5.0/24 enp5s0 hassio
This successfully repeats the correct packets and there are no loops.

data from=10.1.1.164 size=38
repeating data to hassio
skipping packet from=10.2.2.1
skipping packet from=10.5.5.1
data from=10.1.1.134 size=38
repeating data to hassio
skipping packet from=10.2.2.1
skipping packet from=10.5.5.1
data from=10.1.1.164 size=38
repeating data to hassio
skipping packet from=10.2.2.1
skipping packet from=10.5.5.1

I think the users who have this issue are the ones with vlans set up and have more knowledge about the networks so having the -b 10.2.2.0/24 -b 10.5.5.0/24 as an optional configuration option somewhere could be the quickest solution?

Thoughts? @pvizeli @frenck

[mbrackjr]

Awaiting a structural solution (which is really needed as mdns-repeater should NOT be listening on all ports as it results in unwanted mdns-announcements across vlans) i've added a static route to 8.8.8.8/32 towards my loopback interface. That way the hassio-mcast container forwards mdns-announcements on all hassio host interface to the docker-network (which is fine with me) and the hosts' loopback (which is wrong, but doesn't hurt too much at the moment).

[chisale]

I'm glad I found this post. I'm also having same issue. Initially, I stated noticing my hard drive writing logs non-stop and experiencing chromecast problem. I also run UniFi equipments with multiple vlans and mDNS enabled in the controller. At least, I found some workaround for the time being. Thanks.

[mbrackjr]

@frenck @pvizeli
Did you had any chance in looking further into this issue? Jesserockz identified the root-cause and potential solution, so would be very grateful if this can be structurally resolved. Thanks for your great work.

[mkarnebeek]

My issue was caused by having another reflector (avahi) on the network across the same two interfaces as hassio. Since I had that reflector now properly configured, there was no longer a need for hassio to have two interfaces: I removed hassio's second interface and configured my router to allow traffic from hassio to the other network. The router and my own set up reflector are now all that is needed for hassio to reach the second network (dedicated iot network for poorly secured devices, no internet access for example, and a few hosts, like hassio allowed to access that network).

I no longer have issues, so that's maybe worth something. For me it feels more properly set up this way.

[jesserockz]

That will not work for all cases though.
Simple example:
My 10.2.2.X network is a guest wifi. Guest have access to HA to control certain devices but if I then remove the HA machine from that network they will no longer have access.
I just don't think HA should not be the architect of my network layout.

[mbrackjr]

Agree with Jesserockz; I absolutely love HA, but the forced push of this multicast repeater without any form of either disabling it nor customizing it is a wrong move imho. I'm the first to admit my situation is a-typical and actually unwanted, but at the moment I'm forced to have a second network exposed within my HA-running machine.

I understand, and fully respect, that the maintainers can't nor want to support every single possible scenario HA is run in/on, but every forced functionality should be accompanied by a means to interact/influence it, even if its just disabling it (and accepting the corresponding consequences).

I hope @frenck or @pvizeli can respond on their thoughts soon. I'm not a programmer (network guy for profession) so don't feel comfortable to write a pull-request by myself. If someone however can point me in the right direction how I can either define a user-facing option in HA or an admin-facing option on CLI, I'm willing to do an attempt.

[frenck]

@mbrackjr If you like more control, please use Home Assistant Container instead.

[mbrackjr]

@frenck Thanks for responding. I was somehow afraid to get this type of feedback based on similar comments when the manual hassio install method was originally pulled.

I don't want to end up in a discussion of right or wrong; you're one of the primary maintainers of this wonderful project. So if this is the formal statement, I have no option than to 'live with it'.

I do believe however I'm representative of a small percentage of still very happy users of hass.io that is trying to be positively critical in making the product even better. Your own 'about me' seems to me you're self-critical as well, so I sincerely hope you can value my feedback here, rather than dismissing it.

I'm perfectly fine for supervisor to manage my HA stuff and it hasn't given me any problems so far. This multicast-container has, simply because its intended use (get multicast network announcements into HA in support of service-discovery) is not the provided use (repeating all inbound multicast to all other interfaces). The fact it works 'for most', is simply due to the fact that 'most' installations of "Home Assistant Supervised" are using a single network interface. For the outliers/exceptions the solution is not fit-for-purpose and that should not be considered 'good enough' for anyone serious about providing qualitative software, which I believe you are (given your extremely well documented add-ons of the past).

Again, I hope this comes across with its intent; to point out a flaw in the intended use of the provided solution, hoping you're able to help out (either by programming or providing some guidance). Not as negative or critical to your intentions.

Thanks for listening/reading. Manfred

[frenck]

@mbrackjr We are always open for PRs.

I'm sorry that you don't like the response, however, starting with "but the forced push of this multicast repeater without any form of either disabling" is fine, but just saying if you want manual control, this isn't the right system for you.

[Samantha-uk]

I've been seeing the same.
Looking at the various source files, it seems that the underlying mDNS process (Which is https://github.com/kennylevinsen/mdns-repeater/releases/tag/1.11) is started by Home Assistant in 'foreground' mode.
" -f runs in foreground for debugging"

I rebuilt the docker image and injected it into my Home Assistant setup. (A torturous process lol) and ...

• Logging output is much reduced
• Home assistant seems to carry on working without logging any warnings/errors

I was about to make a PR but I see that @pvizeli has made some changes whilst I was 'messing around' lol.

[pessorrusso]

I am also on Unifi (and EdgeRouter), my workaround fixed the issue for me, see my previous comment (Jan 25).

[wittekind]

I've approached this in a different way. As long as HA is still able to find or address devices in other subnets / V-LANs it does not need to be multihomed.

I'll describe my specific situation. While it might not help everyone, it might help some:

I have two major subnets, both on different V-LANs created on UniFi equipment. One is my "home" network, the other is for IoT devices. My control devices (smartphones, computers etc) live on the home network, Chromecast Audios and other renderers live on the IoT network. With HA having interfaces on both network I saw the flooding everyone has issues with. USG does not take kindly to that. But with HA only being present in either one of the network I need the USGs mDNS repeater to make the Chromecasts available in the home network - which is unreliable in itself. But that a USG issue, or rather a Google issue. So the idea of having a reliable mDNS repeater is good - it's just that HA is not that.

Solution: I moved HA to the home network and found a different mDNS repeater: https://github.com/scyto/multicast-relay
It's deployed as Docker container on a Raspberry Pi 4. My network interfaces on that machine are setup a little more complicated, but it works well: There's a macvlan adapter set up on the host for each VLAN. I've created a Docker network with macvlan driver for each VLAN as well. The mDNS repeater is attached to each of the VLANs. If you want to do the same the container needs the names of the interfaces for which you want the repeater to be active. For the attached Docker networks it just counts eth0 upwards, so I've set INTERFACES=eth0 eth1 for my two networks.

I hope this helps someone.

Edit: This solves one problem with Chromecast Audio in particular: Groups. Those usually fall apart across subnets when only using Unifis repeater. I can now use those across subnets.

[blhoward2]

I experienced this same issue with openwrt and disabling ipv6 on my router fixed it.

[pierre2113]

I already have ipv6 turned off, but I also have different home network setup.
My 2 raspberry pi running supervised Home assistant were connected to an access point. for a short time I had to turn off MDNS on all the routers to prevent network outage. After a few changes and HA upgrades I turned MDNS back on all the routers without my network going down, however I started having video streaming issues, video resolution would drop periodically on FireTV Cube but only if the FireTV cube was plugged in to the same Access Point router that the 2 raspberry PI's running HA were connected to. My internet plan was 1Gbit, so it couldn't have been slow internet. I ended up creating a VLAN on the Access point router, and use EBTABLES command to isolate FireTV Cube LAN connection from the 2 HA Lan connections. just for caution I also blocked Multicast/MDNS coming from HA to the FireTV with EBTABLES command. I didn't know how to implement mbrackjr suggested solution to my raspbian os, due to lack of knowledge.

[spudje]

Having same issue. Restarting my USG after restarting Home Assistant seems to take the load away. However I do hope we'll see a structural solution soon.

OK I dived a bit more into this issue.
My setup is a 100% Unifi based network, with USG configured to repeat mDNS.
I have a Home Assistant Blue device, on which I also run the Unifi controller.
However I have it connected to the LAN over 2 VLANs. The IoT VLAN for Home Assistant and the untagged/managed VLAN for the Unifi Controller.
I have a third "main" VLAN for PCs, NAS, Mobile phones. This VLAN is not tagged on the network port where the Home Assistant Blue is connected. Still all Chromecast stuff works fine, so I take it my USG does a proper job in itself with mDNS repeating between IoT and main VLAN.

Since the untagged VLAN is not needed for any of the Home Assistant stuff, can I somehow drop everything that the Home Assistant Blue copies on there when it's coming towards my USG (A LAN-out drop rule????) and will that stop my USG from have high CPU load?

Or should I simply remove the untagged VLAN from the interface/network port with Home Assistant Blue. Will the Unfii controller still see my network devices then?

[spudje]

Well, limiting my Hass Blue to only 1 VLAN does not fix the issue. So probably I don't understand the issue.

[joshuaspence]

Would the team to open to a pull request to allow this container to be configured and/or disabled?

[joshuaspence]

@jesserockz did you ever find a solution/workaround for your problem?

[jesserockz]

@joshuaspence no. I have since moved my install to a Blue so it does not apply to be personally anymore.

But basically you cannot use multiple network interfaces (or vlans) on the host running supervised HA because of this issue.

[joshuaspence]

Ok, fair enough. If the maintainers (@frenck / @pvizeli) would be open to a pull request to fix/improve this behaviour then I am willing to work on it.

[jesserockz]

You won't get anywhere by mentioning them 😉
As long as the PR works, I am sure they will consider it.

[joshuaspence]

I won't be submitting a pull request as I have an alternative solution to my problem. The only reason I want/need multiple network interfaces on Home Assistant is so that Home Assistant would see DHCP requests on all of my subnets, which is needed for DHCP discovery to work.

Most of my integrations rely on mDNS rather than DHCP for discovery and the Unifi mDNS Repeater is working well for this. I realized that the TPLink integration supports another form of discovery, which involves broadcasting on UDP port 9999. I have setup https://github.com/britannic/ubnt-bcast-relay on my USG and Home Assistant can now discover TPLink devices.

[jesserockz]

Ah, DHCP discovery, did not think of that and Dont think any of my devices use that.
But still a valid point to need this to work properly.

[joshuaspence]

Yeah. Another solution I considered was to run the DHCP server add-on on Home Assistant and have my USG relay DHCP requests to Home Assistant but I chose not to do this for two reasons:

1. I didn't want my DHCP configuration split across multiple systems (Unifi for some networks, Home Assistant for others).
2. I didn't want Home Assistant to be a critical part of my network infrastructure.

[agners]

@joshuaspence (or anyone else in this thread), multicast plugin version 2022.02.0 is currently on the beta channel and should not replicate mDNS messages on the main Ethernet interface anymore. You can test it out using the following terminal commands:

ha su options --channel=beta
ha su reload
ha multicast info
ha multicast update

[joshuaspence]

@agners Still testing but one observation so far is that there is a lot of mDNS traffic generated still. It looks like Home Assistant is advertising a whole bunch of services for homeassistantX with increasing integer values of X. Here's a snippet of tcpdump on my router:

22:12:47.832833 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2752.local.:0 0 0 (144)
22:12:47.949325 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2754.local. ANY (QM)? homeassistant2754 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:47.959412 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2754.local.:0 0 0 (144)
22:12:48.070003 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2755 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2755.local. (190)
22:12:48.079747 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2755.local.:0 0 0 (144)
22:12:48.204134 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2763.local. ANY (QM)? homeassistant2763 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:48.324657 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2768.local. ANY (QM)? homeassistant2768 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:48.333135 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2768.local.:0 0 0 (144)
22:12:48.450402 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2769 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2769.local. (190)
22:12:48.466046 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2769.local.:0 0 0 (144)
22:12:48.580807 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2779.local. ANY (QM)? homeassistant2779 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:48.591691 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2779.local.:0 0 0 (144)
22:12:48.702810 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2784 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2784.local. (190)
22:12:48.709970 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2784.local.:0 0 0 (144)
22:12:48.820968 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2785.local. ANY (QM)? homeassistant2785 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:48.834977 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2785.local.:0 0 0 (144)
22:12:48.949141 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2789.local. ANY (QM)? homeassistant2789 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:48.961404 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2789.local.:0 0 0 (144)
22:12:49.070931 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2790 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2790.local. (190)
22:12:49.080363 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2790.local.:0 0 0 (144)
22:12:49.203179 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2792 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2792.local. (190)
22:12:49.210428 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2792.local.:0 0 0 (144)
22:12:49.315484 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2795 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2795.local. (190)
22:12:49.347044 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2801.local. ANY (QM)? homeassistant2801 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:49.539590 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2817.local. ANY (QM)? homeassistant2817 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:49.551889 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2817.local.:0 0 0 (144)
22:12:49.597090 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2824 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2824.local. (190)
22:12:49.715649 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2826.local. ANY (QM)? homeassistant2826 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:49.833730 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2829 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2829.local. (190)
22:12:49.956286 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2830 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2830.local. (190)
22:12:50.075602 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2840.local. ANY (QM)? homeassistant2840 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:50.085781 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2840.local.:0 0 0 (144)
22:12:50.199778 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2845.local. ANY (QM)? homeassistant2845 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:50.322983 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2853.local. ANY (QM)? homeassistant2853 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:50.449103 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2863 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2863.local. (190)
22:12:50.464984 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2863.local.:0 0 0 (144)
22:12:50.578871 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2873.local. ANY (QM)? homeassistant2873 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:50.592346 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2873.local.:0 0 0 (144)
22:12:50.705911 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2881 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2881.local. (190)
22:12:50.722392 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2881.local.:0 0 0 (144)
22:12:50.830493 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2888 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2888.local. (190)
22:12:50.841970 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2888.local.:0 0 0 (144)
22:12:50.956630 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2890.local. ANY (QM)? homeassistant2890 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:51.077413 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2895 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2895.local. (190)
22:12:51.211671 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2901.local. ANY (QM)? homeassistant2901 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:51.217426 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2901.local.:0 0 0 (144)
22:12:51.325784 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2906 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2906.local. (190)
22:12:51.456204 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2913.local. ANY (QM)? homeassistant2913 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:51.571982 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2922 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2922.local. (190)
22:12:51.704562 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2930 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2930.local. (190)
22:12:51.826742 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2931.local. ANY (QM)? homeassistant2931 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:51.836431 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2931.local.:0 0 0 (144)
22:12:51.948597 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2937.local. ANY (QM)? homeassistant2937 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:52.076785 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2942.local. ANY (QM)? homeassistant2942 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:52.083291 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2942.local.:0 0 0 (144)
22:12:52.201462 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2952.local. ANY (QM)? homeassistant2952 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:52.322010 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2961.local. ANY (QM)? homeassistant2961 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:52.328993 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2961.local.:0 0 0 (144)
22:12:52.347220 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2963 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2963.local. (190)
22:12:52.465039 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2967.local. ANY (QM)? homeassistant2967 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:52.473589 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2967.local.:0 0 0 (144)
22:12:52.592789 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2968 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2968.local. (190)
22:12:52.609201 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2968.local.:0 0 0 (144)
22:12:52.721626 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2976 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2976.local. (190)
22:12:52.840391 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2980 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2980.local. (190)
22:12:52.852759 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2980.local.:0 0 0 (144)
22:12:52.961350 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2981.local. ANY (QM)? homeassistant2981 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:52.975437 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2981.local.:0 0 0 (144)
22:12:53.082918 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2985.local. ANY (QM)? homeassistant2985 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:53.211550 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2987.local. ANY (QM)? homeassistant2987 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:53.227982 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2987.local.:0 0 0 (144)
22:12:53.339230 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant2994 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant2994.local. (190)
22:12:53.350717 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant2994.local.:0 0 0 (144)
22:12:53.455261 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3001 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant3001.local. (190)
22:12:53.589043 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3007.local. ANY (QM)? homeassistant3007 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:53.705512 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3014 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant3014.local. (190)
22:12:53.717333 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3014.local.:0 0 0 (144)
22:12:53.824423 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3021 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant3021.local. (190)
22:12:53.839754 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3021.local.:0 0 0 (144)
22:12:53.963668 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3029.local. ANY (QM)? homeassistant3029 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:53.975801 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3029.local.:0 0 0 (144)
22:12:54.082312 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3037.local. ANY (QM)? homeassistant3037 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:54.090731 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3037.local.:0 0 0 (144)
22:12:54.199359 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3041.local. ANY (QM)? homeassistant3041 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:54.337280 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3048.local. ANY (QM)? homeassistant3048 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:54.350567 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3048.local.:0 0 0 (144)
22:12:54.462912 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3051 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant3051.local. (190)
22:12:54.581492 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3057.local. ANY (QM)? homeassistant3057 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:54.701031 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3066 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant3066.local. (190)
22:12:54.711982 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3066.local.:0 0 0 (144)
22:12:54.823400 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3075.local. ANY (QM)? homeassistant3075 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:54.952777 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3085.local. ANY (QM)? homeassistant3085 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:54.967080 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3085.local.:0 0 0 (144)
22:12:55.071868 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3089.local. ANY (QM)? homeassistant3089 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:55.081881 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3089.local.:0 0 0 (144)
22:12:55.201744 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3095 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant3095.local. (190)
22:12:55.210968 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3095.local.:0 0 0 (144)
22:12:55.324176 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3105.local. ANY (QM)? homeassistant3105 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. (190)
22:12:55.453420 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3113 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant3113.local. (190)
22:12:55.460067 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0*- [0q] 2/0/0 (Cache flush) TXT "", (Cache flush) SRV homeassistant3113.local.:0 0 0 (144)
22:12:55.570806 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3116 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant3116.local. (190)
22:12:55.703539 IP homeassistant.spence.network.mdns > 224.0.0.251.mdns: 0 [2q] [3n] ANY (QM)? homeassistant3124 [52e5dda0eaab409ca9da416c0a71f34b]._workstation._tcp.local. ANY (QM)? homeassistant3124.local. (190)

[joshuaspence]

Apart from that, it seems to work I think. I am going to go back to stable though because I already have a workaround and the logs above make me think this still isn't working as I would have expected.

[joshuaspence]

I couldn't figure out where Home Assistant is advertising itself via mDNS but interestingly those homeassistantX names seem to be resolving to one of the secondary VLAN network interfaces rather than the primary interface.

> ha network info
docker:
  address: 172.30.32.0/23
  dns: 172.30.32.3
  gateway: 172.30.32.1
  interface: hassio
host_internet: true
interfaces:
- connected: true
  enabled: true
  interface: eth0
  ipv4:
    address:
    - 192.168.1.100/24
    gateway: 192.168.1.1
    method: auto
    nameservers:
    - 192.168.1.1
  ipv6:
    address:
    - 2403:5808:8904:56:4431:4b50:f8a4:c2c6/64
    - fe80::53b1:fe6f:144b:67fd/64
    gateway: fe80::1ae8:29ff:fe46:55
    method: auto
    nameservers:
    - fe80::1ae8:29ff:fe46:55
  primary: true
  type: ethernet
  vlan: null
  wifi: null
- connected: false
  enabled: false
  interface: wlan0
  ipv4:
    address: []
    gateway: null
    method: disabled
    nameservers: []
  ipv6:
    address: []
    gateway: null
    method: disabled
    nameservers: []
  primary: false
  type: wireless
  vlan: null
  wifi: null
- connected: true
  enabled: true
  interface: eth0.20
  ipv4:
    address:
    - 192.168.20.50/24
    gateway: 192.168.20.1
    method: auto
    nameservers:
    - 192.168.20.1
  ipv6:
    address:
    - fe80::c010:d0a9:ce:8783/64
    gateway: null
    method: auto
    nameservers: []
  primary: false
  type: vlan
  vlan:
    id: 20
    parent: eth0
  wifi: null
- connected: true
  enabled: true
  interface: eth0.10
  ipv4:
    address:
    - 192.168.10.144/24
    gateway: 192.168.10.1
    method: auto
    nameservers:
    - 192.168.10.1
  ipv6:
    address:
    - fe80::21c0:dc28:c43e:6401/64
    gateway: null
    method: auto
    nameservers: []
  primary: false
  type: vlan
  vlan:
    id: 10
    parent: eth0
  wifi: null
supervisor_internet: true

> ping homeassistant1556.local.
PING homeassistant1556.local. (192.168.20.50): 56 data bytes
64 bytes from 192.168.20.50: seq=0 ttl=64 time=0.272 ms
64 bytes from 192.168.20.50: seq=1 ttl=64 time=0.379 ms
64 bytes from 192.168.20.50: seq=2 ttl=64 time=0.229 ms

[spuiuk]

@joshuaspence (or anyone else in this thread), multicast plugin version 2022.02.0 is currently on the beta channel and should not replicate mDNS messages on the main Ethernet interface anymore. You can test it out using the following terminal commands:

ha su options --channel=beta
ha su reload
ha multicast info
ha multicast update

I had hit the same problem which had overwhelmed the network printer on my network. While debugging this I came across the mdns storm on my network which seems to have completely overwhelmed my printer. I have since updated my hassio_multicast from the beta channel as you specified and it has fixed my issue.

I am using the edgerouter x with multiple vlans and the mdns repeater enabled on the router. I had come across a similar issue a couple of years ago too - https://community.home-assistant.io/t/mdns-flood/223415

[pierre2113]

I've been without multicast feedback loop network issue for almost 19 months now, until 3 days ago, around 5am local time multicast traffic jumped to almost 500bytes/sec from 15bytes/sec. I've placed multicast bytes/sec monitoring for about 6 months now.
I've implemented every solution I've read here and other places, ebtables, vlan, etc. I just put the supervisor beta channel it seems to have done the trick. I have 2 HA's, one of them I upgraded HA later that morning, the other I didn't both I switched the HA supervisor to beta channel as quickly as i could, shortly after my network didn't crash every 10 minutes. I upgrade raspbian on both HA hardware.

One common denominator when my network gets hit with multicast feedback loop, is I've stopped updating both raspbian OS and Home assistant. This time I haven't updated it for about 3 months now (raspbian + HA) at the same time.
Makes me wonder when an update is available it un-intentionally triggers this problem,
Updating raspbian OS also updated docker, docker could be a suspect too.

[agners]

@joshuaspence

@agners Still testing but one observation so far is that there is a lot of mDNS traffic generated still. It looks like Home Assistant is advertising a whole bunch of services for homeassistantX with increasing integer values of X. Here's a snippet of tcpdump on my router:

Those do not seem to be caused by the multicast plug-in.

I couldn't figure out where Home Assistant is advertising itself via mDNS but interestingly those homeassistantX names seem to be resolving to one of the secondary VLAN network interfaces rather than the primary interface.

That might be related to the primary network device auto detection in Core (see https://www.home-assistant.io/integrations/network/). Try selecting the right interface manually to see if that improves.

While there might be still something odd, it seems to me that those messages are "genuine" and not reflected/amplified by the multicast plug-in.

[agners]

@pierre2113

I've been without multicast feedback loop network issue for almost 19 months now, until 3 days ago, around 5am local time multicast traffic jumped to almost 500bytes/sec from 15bytes/sec.

Here too, this might be some additional messages, not really a feedback loop. Can you check what kind of messages those are?

[joshuaspence]

@agners I did try selecting the primary network interface instead of relying on the auto-detection but it didn't help.

I believe the problem I described is caused by the multicast plugin as it stopped immediately when I stopped the multicast container. I think what I observed was a loop, just not necessarily a positive feedback loop.

[agners]

@joshuaspence ok, you have the latest 2022.02.0 installed I assume? (ha multicast info)

[joshuaspence]

Yes

[pierre2113]

@agners
I don't have logs of actual messages, on my ASUS router running merlin firmware I poll /proc/net/dev every 5 min (the 9th column is labeled multicast I sum up that column on interfaces eth0-eth7 using awk command line) , I bring the data as a sensor I divided it by the delta time in between polls and display as a history graph in bytes/sec. The upward spike 1 hour before I woke up that morning coincides with network outage. So I know its multicast traffic, for the past 6 months it hasn't gone about 50 bytes/sec, even that it usually is a short burst, that morning it jumped to 500bytes/sec and stayed at 500 bytes/sec for an hour until I woke up, and all my devices alexa's/google hubs were complaining no internet.

[noci2012]

When the network is in trouble, this seems to be happening....
Probably two multicast repeaters sending back to the receipient...
It causes one core in the firewall to be completely consumed, and quite some load on the LAN.
(avahi-reflection is enable on the firewall to allow MDNS traffic between several VLAN's, one of which is where HA is installed)

Dec 02 15:37:58 homeassistant systemd-resolved[389]: Detected conflict on homeassistant223041.local IN A 192.168.XX.66
Dec 02 15:37:58 homeassistant systemd-resolved[389]: Hostname conflict, changing published hostname from 'homeassistant223041' to 'homeassistant223044'.
Dec 02 15:37:58 homeassistant systemd-resolved[389]: Detected conflict on homeassistant223044.local IN A 192.168.XX.66
Dec 02 15:37:58 homeassistant systemd-resolved[389]: Hostname conflict, changing published hostname from 'homeassistant223044' to 'homeassistant223048'.
Dec 02 15:37:58 homeassistant systemd-resolved[389]: Detected conflict on homeassistant223048.local IN A 192.168.XX66
Dec 02 15:37:58 homeassistant systemd-resolved[389]: Hostname conflict, changing published hostname from 'homeassistant223048' to 'homeassistant223058'.
Dec 02 15:37:59 homeassistant systemd-resolved[389]: Detected conflict on homeassistant223058.local IN A 192.168.XX.66
Dec 02 15:37:59 homeassistant systemd-resolved[389]: Hostname conflict, changing published hostname from 'homeassistant223058' to 'homeassistant223059'.
Dec 02 15:37:59 homeassistant systemd-resolved[389]: Detected conflict on homeassistant223059.local IN A 192.168.XX.66
Dec 02 15:37:59 homeassistant systemd-resolved[389]: Hostname conflict, changing published hostname from 'homeassistant223059' to 'homeassistant223063'.