SOLVED SMB mDNS Service Discovery Broken / macOS Ventura Can No Longer See TrueNAS

alexmarkley · Sep 8, 2023

Good evening! I've been running TrueNAS-SCALE-22.12.3.2 for the last month with a handful of SMB shares (among other things) and everything has been working great.

I use SMB shares primarily from macOS clients. I have shares for file sharing and shares for Time Machine.

At some point over the last few days, mDNS service discovery for SMB has stopped working for my TrueNAS box. My machines are all connected via physical ethernet cables and I can manually connect to my TrueNAS box via Finder -> Go -> Connect to Server -> smb://veritas2 (the host name of my TrueNAS box).

To be clear, I've tried two different macOS machines, each running two different versions of Ventura. Both are having the same trouble. I've tried various troubleshooting steps, such as the standard sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder nonsense on the client, with no success.

Digging deeper, I went into TrueNAS SCALE -> Network -> Global Configuration -> Settings -> Service Announcement and I toggled mDNS off and back on. (Of course I had to temporarily disable my Time Machine shares to do this, but they weren't working anyway.)

What's weird is, most of the time after I enable mDNS I can briefly see veritas2 flash in Finder before it disappears again. Digging deeper, I ran some tcpdump and dns-sd commands on my client while enabling mDNS on TrueNAS.

Here's what I got:

Code:

Lapis:~ alex$ sudo tcpdump -n host 224.0.0.251 and port 5353
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes
17:35:55.424680 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/0 PTR _smb._tcp.local., PTR veritas2._device-info._tcp.local., PTR _device-info._tcp.local., PTR veritas2._http._tcp.local., PTR _http._tcp.local., PTR veritas2._smb._tcp.local. (180)
17:35:55.566282 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0 [2q] [2n] ANY (QM)? 50.1.77.10.in-addr.arpa. ANY (QM)? veritas2.local. (91)
17:35:55.816068 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0 [2q] [2n] ANY (QM)? 50.1.77.10.in-addr.arpa. ANY (QM)? veritas2.local. (91)
17:35:56.067936 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0 [2q] [2n] ANY (QM)? 50.1.77.10.in-addr.arpa. ANY (QM)? veritas2.local. (91)
17:35:56.267885 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) PTR veritas2.local., (Cache flush) A 10.77.1.50 (79)
17:35:56.566479 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0 [3q] [6n] ANY (QM)? veritas2._smb._tcp.local. ANY (QM)? veritas2._device-info._tcp.local. ANY (QM)? veritas2._http._tcp.local. (233)
17:35:56.816784 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0 [3q] [6n] ANY (QM)? veritas2._smb._tcp.local. ANY (QM)? veritas2._device-info._tcp.local. ANY (QM)? veritas2._http._tcp.local. (233)
17:35:57.067545 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0 [3q] [6n] ANY (QM)? veritas2._smb._tcp.local. ANY (QM)? veritas2._device-info._tcp.local. ANY (QM)? veritas2._http._tcp.local. (233)
17:35:57.268420 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0*- [0q] 13/0/0 (Cache flush) TXT "", PTR veritas2._device-info._tcp.local., (Cache flush) SRV veritas2.local.:9 0 0, (Cache flush) A 10.77.1.50, (Cache flush) TXT "model=MacPro7,1@ECOLOR=226,226,224", PTR _device-info._tcp.local., PTR veritas2._http._tcp.local., (Cache flush) SRV veritas2.local.:80 0 0, (Cache flush) TXT "", PTR _http._tcp.local., PTR veritas2._smb._tcp.local., (Cache flush) SRV veritas2.local.:445 0 0, PTR _smb._tcp.local. (338)
17:35:57.287415 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0*- [0q] 14/0/0 (Cache flush) A 10.77.1.50, (Cache flush) PTR veritas2.local., PTR veritas2._device-info._tcp.local., (Cache flush) SRV veritas2.local.:9 0 0, (Cache flush) TXT "model=MacPro7,1@ECOLOR=226,226,224", PTR _device-info._tcp.local., PTR veritas2._http._tcp.local., (Cache flush) SRV veritas2.local.:80 0 0, (Cache flush) TXT "", PTR _http._tcp.local., PTR veritas2._smb._tcp.local., (Cache flush) SRV veritas2.local.:445 0 0, (Cache flush) TXT "", PTR _smb._tcp.local. (375)
17:35:57.439216 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0*- [0q] 6/0/0 PTR _smb._tcp.local., PTR veritas2._device-info._tcp.local., PTR _device-info._tcp.local., PTR veritas2._http._tcp.local., PTR _http._tcp.local., PTR veritas2._smb._tcp.local. (180)
17:35:57.569038 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0 [2q] [2n] ANY (QM)? 50.1.77.10.in-addr.arpa. ANY (QM)? veritas2.local. (91)
17:35:57.818870 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0 [2q] [2n] ANY (QM)? 50.1.77.10.in-addr.arpa. ANY (QM)? veritas2.local. (91)
17:35:58.070280 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0 [2q] [2n] ANY (QM)? 50.1.77.10.in-addr.arpa. ANY (QM)? veritas2.local. (91)
17:35:58.270876 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) PTR veritas2.local., (Cache flush) A 10.77.1.50 (79)
17:35:59.350712 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) PTR veritas2.local., (Cache flush) A 10.77.1.50 (79)
17:36:01.431840 IP 10.77.1.50.5353 > 224.0.0.251.5353: 0*- [0q] 2/0/0 (Cache flush) PTR veritas2.local., (Cache flush) A 10.77.1.50 (79)

^C
17 packets captured
1095 packets received by filter
0 packets dropped by kernel
Lapis:~ alex$

Code:

Lapis:~ alex$ dns-sd -B _smb._tcp.
Browsing for _smb._tcp.
DATE: ---Fri 08 Sep 2023---
17:35:47.309  ...STARTING...
Timestamp     A/R    Flags  if Domain               Service Type         Instance Name
17:35:57.276  Add        2  21 local.               _smb._tcp.           veritas2
17:35:58.393  Rmv        0  21 local.               _smb._tcp.           veritas2

^C
Lapis:~ alex$

Note the timestamps. Around 17:35:55, I enabled mDNS on TrueNAS SCALE. A couple of seconds later, at 17:35:57, veritas2 is discovered by the client, and it appears in Finder. Just over a second later, at 17:35:58, veritas2 disappears.

I don't know much about the mDNS protocol, but I can't help but think there has to be some kind of race condition at play here. Why does TrueNAS send out cache flush packets right after the initial announcement? Is that normal? Those packets are the only mDNS traffic I can observe happening right when dns-sd says the _smb._tcp. service is being removed.

I'm also confused why this issue started just now. I've been using these SMB shares for several weeks without any issues. I've been running TrueNAS-SCALE-22.12.3.2 that whole time.

I have made changes to the networking configuration and added some virtual machines to this host, but those changes should have been isolated to the secondary network interface and I can't think of anything that would account for this issue.

Can anybody point me in the right direction here? Thanks!

simdim · Sep 13, 2023

I am having the same issue MacOS 13.5.2 TrueNAS TrueNAS-SCALE-22.12.3.3

alexmarkley · Sep 18, 2023

I'm still looking for some guidance on this. Has anybody else encountered or solved this problem before?

Whattteva · Sep 18, 2023

I always wonder why people bother to use that unreliable protocol. I stopped using it at FreeNAS 8.x when I came across this issue. It seems to be it either works all the time for some people, or for others, never works or intermittently fails.

I just setup an actual local DNS in my router and connect to all my services through the DNS name. It's way more reliable and works 100% all the time. If it doesn't, it's because there's a problem with my actual physical network or my router is down, etc.

sretalla · Sep 19, 2023

What other services are you running on your SCALE system...

As I understand it, mDNS is a consumer of broadcast, so would potentially be one of the things that gets broken with you use Apps and/or VMs without implementing a bridge:

Accessing NAS From a VM

Provides instructions on how to create a bridge interface for the VM and provides Linux and Windows examples.

www.truenas.com

alexmarkley · Sep 19, 2023

Whattteva said:
I just setup an actual local DNS in my router and connect to all my services through the DNS name.

I'm also using local DNS for almost everything. Unfortunately, for macOS client, Time Machine requires mDNS to discover the backup server, otherwise it refuses to run the backup. I have not found a workaround for this, so my clients have gone a few weeks without a backup now. :(

sretalla said:
What other services are you running on your SCALE system...

As I understand it, mDNS is a consumer of broadcast, so would potentially be one of the things that gets broken with you use Apps and/or VMs without implementing a bridge:

I definitely started using VMs on my system at some point during the window that mDNS "broke". I have a couple of docker apps running too, but those were already running when mDNS was still working.

In order to make the VMs behave the way I wanted them to, I definitely made changes to my networking configuration. Here's a snapshot of the configuration right now:

Code:

eno1np0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 10.77.1.50  netmask 255.255.0.0  broadcast 10.77.255.255
        ether 3c:ec:ef:c8:3f:74  txqueuelen 1000  (Ethernet)
        RX packets 961863125  bytes 813493722842 (757.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 18
        TX packets 1337183034  bytes 3346387585823 (3.0 TiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno2np1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::3eec:efff:fec8:3f75  prefixlen 64  scopeid 0x20<link>
        ether 3c:ec:ef:c8:3f:75  txqueuelen 1000  (Ethernet)
        RX packets 7628647  bytes 2438192310 (2.2 GiB)
        RX errors 0  dropped 0  overruns 0  frame 18
        TX packets 3517578  bytes 1812503688 (1.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

kube-bridge: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 172.16.0.1  netmask 255.255.0.0  broadcast 172.16.255.255
        inet6 fe80::8c3:72ff:fe37:631b  prefixlen 64  scopeid 0x20<link>
        ether 4a:b7:63:fa:5c:e3  txqueuelen 1000  (Ethernet)
        RX packets 38468660  bytes 700954717342 (652.8 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 251036672  bytes 18389042724 (17.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

kube-dummy-if: flags=195<UP,BROADCAST,RUNNING,NOARP>  mtu 1500
        inet 172.17.0.1  netmask 255.255.255.255  broadcast 0.0.0.0
        inet6 fe80::d468:3aff:feb9:f74c  prefixlen 64  scopeid 0x20<link>
        ether 22:09:fd:7b:2f:d6  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 259  bytes 18130 (17.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 14428284  bytes 3887597034 (3.6 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14428284  bytes 3887597034 (3.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

macvtap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::2a0:98ff:fe7d:6425  prefixlen 64  scopeid 0x20<link>
        ether 00:a0:98:7d:64:25  txqueuelen 500  (Ethernet)
        RX packets 542576  bytes 162224768 (154.7 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 663695  bytes 613142856 (584.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

macvtap5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::2a0:98ff:fe18:f7c6  prefixlen 64  scopeid 0x20<link>
        ether 00:a0:98:18:f7:c6  txqueuelen 500  (Ethernet)
        RX packets 29111  bytes 13299363 (12.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 34821  bytes 7939282 (7.5 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

macvtap6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::2a0:98ff:fe3a:332a  prefixlen 64  scopeid 0x20<link>
        ether 00:a0:98:3a:33:2a  txqueuelen 500  (Ethernet)
        RX packets 29834  bytes 5248833 (5.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 20800  bytes 4882329 (4.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

macvtap7: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::2a0:98ff:fe31:900a  prefixlen 64  scopeid 0x20<link>
        ether 00:a0:98:31:90:0a  txqueuelen 500  (Ethernet)
        RX packets 22154  bytes 9690332 (9.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 31546  bytes 5144833 (4.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

macvtap8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::2a0:98ff:fe46:d022  prefixlen 64  scopeid 0x20<link>
        ether 00:a0:98:46:d0:22  txqueuelen 500  (Ethernet)
        RX packets 19416  bytes 8728486 (8.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11431  bytes 3210313 (3.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

veth872c19da: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::88a8:26ff:fef8:7997  prefixlen 64  scopeid 0x20<link>
        ether 8a:a8:26:f8:79:97  txqueuelen 0  (Ethernet)
        RX packets 2818113  bytes 268526717 (256.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3155841  bytes 282244636 (269.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vetha36968cf: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::6483:38ff:fecd:39  prefixlen 64  scopeid 0x20<link>
        ether 72:83:f0:43:3c:4f  txqueuelen 0  (Ethernet)
        RX packets 3582  bytes 408774 (399.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 2212  bytes 323995 (316.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethd8a7f3c5: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::d4e5:3dff:fee0:a030  prefixlen 64  scopeid 0x20<link>
        ether d6:e5:3d:e0:a0:30  txqueuelen 0  (Ethernet)
        RX packets 4644562  bytes 936968727 (893.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5400231  bytes 1740969025 (1.6 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethf47c716f: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::b875:d1ff:fec1:bf0  prefixlen 64  scopeid 0x20<link>
        ether ca:8e:2d:35:39:6e  txqueuelen 0  (Ethernet)
        RX packets 1636240  bytes 40085935029 (37.3 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 14608696  bytes 965654812 (920.9 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vlan8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 3c:ec:ef:c8:3f:75  txqueuelen 1000  (Ethernet)
        RX packets 1587640  bytes 450536465 (429.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 696 (696.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vlan70: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 3c:ec:ef:c8:3f:75  txqueuelen 1000  (Ethernet)
        RX packets 1672022  bytes 464859262 (443.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 8  bytes 696 (696.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vlan77: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 3c:ec:ef:c8:3f:75  txqueuelen 1000  (Ethernet)
        RX packets 938656  bytes 276122209 (263.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 918735  bytes 684469326 (652.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vlan128: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 3c:ec:ef:c8:3f:75  txqueuelen 1000  (Ethernet)
        RX packets 820452  bytes 144796237 (138.0 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 497168  bytes 115992661 (110.6 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vlan250: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 3c:ec:ef:c8:3f:75  txqueuelen 1000  (Ethernet)
        RX packets 738126  bytes 699536706 (667.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1242767  bytes 791737412 (755.0 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vlan251: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 3c:ec:ef:c8:3f:75  txqueuelen 1000  (Ethernet)
        RX packets 800578  bytes 213126793 (203.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 808048  bytes 202872581 (193.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Here's my explanation:

I use managed switches and VLANs on my network to segment traffic into buckets for different purposes and for different levels of trust. My TrueNAS machine has two physical 10gbe interfaces:

Interface zero is set up as the "NAS / Management" interface, and the switch forces all of that traffic to be on a particular VLAN.
Interface one is connected to a trunk port, and it's allowed to send tagged traffic onto multiple VLANs.

Each virtual machine on my SCALE box is connected to a particular VLAN interface, which forces that VM to be on a particular VLAN. The advantage of this is that traffic between the VM and the NAS must travel through the firewall and be subject to inspection by Suricata. This is necessary because some of these virtual machines are actually exposed directly to the Internet via port forwarding.

Back to the NAS, ideally it should just be doing its thing on eno1np0? The macOS clients in question here are sitting on the same VLAN and (I have double-checked) none of that traffic is being inspected or filtered by the firewall because it never leaves the 10gbe switch.

If I did manage to break something with this network configuration, I'd be very interested if someone could recommend some troubleshooting steps I could try.

My hope is to find a working configuration that keeps TrueNAS traffic on interface zero and keeps all VM traffic (segmented by VLANs) on interface one.

sretalla · Sep 19, 2023

You need to have a bridge for every VLAN for broadcast to work properly and assign the IP of the host to the bridge on that appropriate VLAN/NIC.

It should go like this:

Physical adapter -> LAGG (if you're doing that) -> VLAN (if you have VLANs) -> Bridge (IP address of host goes here if it will have an address on that VLAN).

alexmarkley · Sep 19, 2023

sretalla said:
You need to have a bridge for every VLAN for broadcast to work properly and assign the IP of the host to the bridge on that appropriate VLAN/NIC.

Is that true even if I want to separate my NAS broadcast traffic from my VM traffic? I do not want TrueNAS to be broadcasting onto any interfaces except eno1np0.

Also, to be clear, I do see mDNS traffic coming across my macOS client. If there was a network configuration issue I would expect the number of mDNS packets to be zero.

I might look into shutting off all the VMs and deleting the extra network configuration as a test.

sretalla · Sep 19, 2023

As soon as you have anything going on with VMs, you need to abstract your host's own connection from all the other connections by using a bridge (think of it as a Virtual switch).

That ensures that traffic from the host is clear and distinct (even to the host itself) from all the other traffic passing on the NIC.

By all means do the test you're talking about, but I imagine the solution will be the bridge (at very least on the host NIC, but maybe also on the ones carrying VMs)

alexmarkley · Sep 19, 2023

Well, this is really interesting. If I stop all of my VMs and delete all of the supporting vlan* interfaces, mDNS starts working.

I tried building the Physical NIC -> VLAN -> Bridge structure for each VM, and mDNS broke again.

I'm going to walk through the whole setup again more slowly and see if I can isolate the specific configuration change that kills it.

alexmarkley · Sep 19, 2023

Okay, I think this is solved. Thank you @stretalla for providing the key clue to solving this issue.

TL;DR, my working network structure now looks like:

Physical NIC 0 (no IP)
- Bridge 0 (br0) with host IP address.
Physical NIC 1 (no IP)
- VLAN X (vlanX) (no IP)
- VLAN Y (vlanY) (no IP)
- VLAN Z (vlanZ) (no IP)

My VMs are attached to the various vlanXYZ interfaces with no additional bridge interfaces required. The host IP address needs to be assigned to br0 interface even though there are no other users of this interface.

I still do not understand why this the bridge interface is necessary. Technically you don't even need any VMs running to break things.

mDNS will break if I even just build this network configuration, even if I don't start any VMs:

Physical NIC 0 with host IP
Physical NIC 1 (no IP)
- VLAN X (vlanX) (no IP)

I guess if this is expected behavior, I would be interested in understanding why. But regardless, I have a functioning workaround now, so I'm happy!

sretalla · Sep 20, 2023

alexmarkley said:
I guess if this is expected behavior, I would be interested in understanding why. But regardless, I have a functioning workaround now, so I'm happy!

I learned about the "broken multicast" issue from @Patrick M. Hausen (who discusses it a lot in helping folks on CORE/FreeBSD=UNIX). I think I could find a dozen posts where he says it's not allowed to have a bridge member with a layer 3 address... but that's UNIX.

Looking for explanations specifically for linux hasn't turned up a nice clear set of words, but I'm going to have a shot at explaining it with this:

In the documentation for Linux bridges (https://www.man7.org/linux/man-pages/man8/bridge.8.html), you have this:

mcast_router MULTICAST_ROUTER
This flag is almost the same as the per-VLAN flag, see
below, except its value can only be set in the range 0-2.
The default is 1 where the bridge figures out
automatically where an IGMP/MLD querier, MRDISC capable
device, or PIM router, is located. Setting this flag to 2
is useful in cases where the multicast router does not
indicate its presence in any meaningful way (e.g. older
versions of SMCRoute, or mrouted), or when there is a need
for forwarding both known and unknown IP multicast to a
secondary/backup router.

My guess as to why it doesn't work properly without a bridge is that I don't think a NIC (just the interface) has such a setting with the default to handle that, so as soon as you have more than a single NIC in the system, multicast is no good and you need the bridge interface code to work it out for you.

simdim · Sep 20, 2023

In my setup I have
NIC1 - 192.168.1.10/24 SMP/mDNS/WebGUI
NIC2 - No IP
Br1 - 192.168.1.20/24 VM/APPS

Are we saying I should not have IP on NIC1 and need to introduce another bridge?

Patrick M. Hausen · Sep 20, 2023

You cannot have IP addresses from the same /24 on two different interfaces.

simdim · Sep 20, 2023

Yes that what I had got from documentation, but I do not really need that IP on VM/Apps bridge do I?

This should work and allow for mDNS to function properly?

NIC1 - No IP
Br0 - 192.168.1.10/24 SMP/mDNS/WebGUI
NIC2 - No IP
Br1 - No IP. VM/APPS

Patrick M. Hausen · Sep 20, 2023

Yes. And if there are no VMs on NIC1, you should not need a bridge on that NIC at all. You need a bridge where you connect VMs.

And IF the NAS needs an IP address in that network, then it must be on the bridge, not the member.

But apps do need an IP address on the host interface, so best move apps to NIC1 without bridge and VMs to NIC2 without IP address but with bridge.

simdim · Sep 20, 2023

Patrick M. Hausen said:
Yes. And if there are no VMs on NIC1, you should not need a bridge on that NIC at all. You need a bridge where you connect VMs.

And IF the NAS needs an IP address in that network, then it must be on the bridge, not the member.

But apps do need an IP address on the host interface, so best move apps to NIC1 without bridge and VMs to NIC2 without IP address but with bridge.

Thank you. That was the logic for the setup originally ... unfortunately, this means that bridge solution not going to solve my disappearing mDNS issue ...

alexmarkley · Sep 20, 2023

Patrick M. Hausen said:
Yes. And if there are no VMs on NIC1, you should not need a bridge on that NIC at all. You need a bridge where you connect VMs.

This turned out not to be true for me. I needed a bridge for TrueNAS/mDNS on NIC0 even though there were no VMs on that NIC.

And on the other hand, on NIC1, I have all of my VMs connected to a series of VLAN interfaces and there are no bridge interfaces at all. :)

simdim said:
Thank you. That was the logic for the setup originally ... unfortunately, this means that bridge solution not going to solve my disappearing mDNS issue ...

You might consider trying it anyway. As I mentioned above, I never had any VMs connected on my first NIC (you're calling it NIC 1, I was calling it NIC 0) and my mDNS quit working regardless.

Patrick M. Hausen · Sep 20, 2023

I must admit that I don't know Linux networking as well as FreeBSD - so whatever is happening under the hood there .... no idea.

With FreeBSD bridge members are layer 2 ports. And bridges are only necessary where you connect VMs or jails. Sorry I can not be more of help here.

alexmarkley · Sep 20, 2023

Patrick M. Hausen said:
I must admit that I don't know Linux networking as well as FreeBSD

As I mentioned above, I have no idea why this is necessary. Consider my experience to be a cautionary tale for others. :D

Important Announcement for the TrueNAS Community.

SOLVED SMB mDNS Service Discovery Broken / macOS Ventura Can No Longer See TrueNAS

Dabbler

Explorer

Dabbler

Wizard

Powered by Neutrality

Dabbler

Powered by Neutrality

Dabbler

Powered by Neutrality

Dabbler

Dabbler

Powered by Neutrality

Explorer

Hall of Famer

Explorer

Hall of Famer

Explorer

Dabbler

Hall of Famer

Dabbler

Similar threads