So to sum this up- i still need RPI and that mdns reflector (https://github.com/kennylevinsen/mdns-repeater) to make it work?
Congrats!
For anyone using Unifi APs (and switches), just keep your MT as your core router. I was looking forward to everything in the Unifi console.
The USG has an issue with CIDRs bigger than /24, no real easy way to ingest large IP lists and the GEO IP (still in beta) filtering has no way to whitelist.
I’m testing the USG as a LAN only repeater, but I think I’ll spin this up in a virtualbox vm.
jwb
As far as MT doesn’t allow to build own package - yes. Any linux box with 2 interfaces can compile&run this mdns-repeater tool I think.
I finally got down to this on the list. Installed on PI running ubuntu. Followed your journal, and chrisreinking blog and so far no issues. I installed all the avahi components via the chrisreinking blog.
I grabbed the ports from https://support.sonos.com/s/article/688?language=en_US. I opened only what I wanted to back to my private LAN.
1400, 3400, 3401, and 3500 Sonos app contr (tcp)
443 (tcp)
4070 spotifyconnect (tcp) - I not sure what this does. I cant stream from my desktop to my sonos.
1900, 1901 Sonos app control (udp)
5252 spotifyconnect (udp)
jwb
any updates since 2020 re working method to get Chromecast across VLANs? Do I still have to get external device (RPI, etc) to get it working?
Has mDNS changed since 2020? If not, then why would the recommended solution need to be changed?
I don’t have this thread’s particular problem (just related ones 
) but what I see up-thread looks sensible to me.
Do I still have to get external device (RPI, etc) to get it working?
The recommended solution uses it as an end-around the VLAN level by having it join both networks in question. You might have your phone on the trusted network and your smart TV on the untrusted one, so you need something on both networks to bridge them. Since this should work all the time, you need an always-on device that is powerful enough to let you run arbitrary software on it. That doesn’t have to be a Raspberry Pi, just something on that order. There are probably dozens of sensible alternatives:
- a Mac Mini
- an always-on Windows machine running WSL2
- the same machine running Linux in a virtual machine
- the more advanced sort of NAS that has add-on software packages (Synology, Drobo, TrueNAS…)
A Pi is a good choice simply because it’s cheap, small, power-efficient, and runs a server-grade OS, so you can make it do what you need.
All of this being said, if you didn’t have such a device and weren’t willing to add one, you could set up PIM-SM. That’s what it’s for. It’s complicated, but that’s because it solves a complicated problem.
(Any one given use of multicast may be simple, but getting all of them working together as you wish can be quite complicated.)
With RouterOS 7.1rc3 … would a docker image be usable?
https://github.com/monstrenyatko/docker-mdns-repeater
In principle, yes. From a skim of the relevant docs, it looks like you just need to assign the container’s “veth” devices to the proper VLANs to let it see both sides. At that point, it’s the same as having a Pi attached to both, so the rest of the tutorial above should then work.
Let us know how it goes. 
seems there is progress what may simplifies the usage of Docker
said in v7.1rc3 adds Docker (TM) compatible container support
\
by the way are you aware of mDNS repeater feature wherein the same thing is discussed?
Worked like a charm. Ended up needing to do a
sudo apt-get install --reinstall build-essential
to get it to make, but once I did that lastly ran ./mdns-repeater br0 br0.20
After that I immediately was able to use airplay across VLANs.