Allow mdns to exclude certain interface from advertising (e.g. management port) OR introduce ordering interface priorities
Intel i5 on Q87 chipset with Intel network cards.
With multiple interfaces configured, it appears the first one (?) is used to advertise services on mdns.
If you use Link Aggregation like me, then you have a problem if you want that to be your main interface for clients that use mdns, e.g. Mac clients.
I use em0 as my "management port" but I want all clients to go through lagg0. I keep the "management port" on the same network because I like using it sometimes for certain things, file transfers, etc, without disrupting the normal lagg0 traffic. But even if you put it onto another network entirely, the problem won't go away as it'll still keep advertising the same IPs as long as the interface is configured.
Going to Services and changing the settings to only listen to lagg0 IPs does nothing. It looks like mdns is set to advertise whatever interface is "first".
If there was a way to reorder interfaces to the priority you want (like you can on OS X), or if there was a way to disable interfaces for mdns such that it uses the next available interface instead, that would fix this.
That's why avahi had the 'deny-interfaces' and 'allow-interfaces' options, which were REALLY handy. We need something like this for the current mdns implementation.
#2 Updated by T F over 3 years ago
Seconding this. I've been trying to track down this exact issue and finally found your forum thread @ https://forums.freenas.org/index.php?threads/disable-mdns-on-management-interface.55766/ which led me to this & https://bugs.freenas.org/issues/24942
Currently my FreeNAS systems are broadcasting out a management vlan interface so none of my mac clients on other vlans can see them in Finder.app
EDIT: Actually, my issue might be a bit different than yours or maybe you hacked something ... my mac clients on vlanX don't even see the advertisements FreeNAS is sending on vlanY. You seem to be implying your mac clients on vlanX do see the advertisement, but it's to an IP address that is bound to vlanY on the FreeNAS side therefore they cannot connect?
#3 Updated by Ash Gokhale over 3 years ago
This is odd - we are seeing it in the field as well I'm not sure if where this bug is yet.
mdns respondr is binding to 0.0.0.0:5353; the mcast frame arrives at the (alternate) interface, but it's never getting the frames at recvmsg.
I will be working this from the bug side; I'm inclined to make the feature req a dup.
#4 Updated by Siegfried Leonard over 3 years ago
Thanks so much for looking into this guys so quickly. It's great to see such non-critical bugs are still dealt with a serious manner. Way to go! :)
Sorry if this message is distracting. Just want to thank you for your work and if there is a way I can help with testing or something, let me know. Thanks!