Yes, the question is, why separate the IoT, if you don’t really need to separate ?
mDNS is not a NAT or Routing, it simply supplies an address
for work already the two VLAN must communicate to eachother and…
why formerly separated VLAN, but effectively not?
The device also MUST be compatible whit mDNS
mDNS devices do not need any mDNS “proxy” if already are on same broadcast domain
All these devices are studied to be all on same wired/wireless network, not to different VLAN.
Just some users on this forum or very advanced users use VLAN in house,
99,9% do not matter if are VLAN or not, 99,8% also do not know what ia a VLAN.
It’s not entire nonsense, sometimes it’s not possible to do it differently.
Here’s example: you have an IoT gadget. It might not need internet, so you want to block internet access for it. Fine, you can use IP firewall filter if you know gadget’s IP address. The later part can be tricky with IPv6 and dynamic addresses (constructed with aide of SLAAC), but you can still filter that according to gadget’s MAC address. But even that is not fail safe, Apple in particular (and others as well) started to “anonymize” MAC address … good luck catching that.
But even if you successfully block access to internet: user might want to restrict access of device to LAN services. And that’s not easy to do if all devices belong to same L2 network.
Having separate L2 network for IoT devices solves all above mentioned problems without too much fuss. But then there comes auto-discovery where many (probably most) vendors simply expect that everything attaches to same L2 network (hence need for mDNS proxying) unless gadget registers directly to some cloud. Which is probably how network looks like for 99% of home users, but those mostly are not interested in running Mikrotik gear.
Personally I couldn’t care less about mDNS and all that automagical stuff. But I still find problematic attitude of Mikrotik about not implementing service, which is enforced by major players and used by home users more and more. If MT wants to stay alive in SOHO segment, then they’ll have to implement those features whether they like them or not.
you have an IoT gadget It might not need internet so you want to block internet access for it
Simply do not provide a gateway and DNS on lease
you can use IP firewall filter if you know gadget’s IP address
…no…
The later part can be tricky with IPv6 and dynamic addresses…
…no… go out only know/allowed devices, if anonymize MAC, never go out
but you can still filter that according to gadget’s MAC address
…ok…
But even that is not fail safe, Apple in particular (and others as well) started to “anonymize” MAC address…
do not buy Apple devices… or filter device with “2nd lower bit set” (000000!0) .. I do not know if is legal to change randomly the MAC (how much random?)
good luck catching that.
…but on this way you still have MAC allowed to out, not a list of blocked MAC…
user might want to restrict access of device to LAN services
why? what can do a device without internet to a light bulb, to a PC? etc.?.
And that’s not easy to do if all devices belong to same L2 network.
…really… is easy…
Having separate L2 network for IoT devices solves all above mentioned problems
…yes but… still no see any problem with IoT devices on same L2 network of my PC…
Why a separate IoT vlan? because I want it, and why have a Mikrotik router at home and use it as a stupid ISP HG(aka router)?
I want to have control of devices that I don’t fully trust, those “black boxes”, and having a vlan for it, I isolate it from the L2 domain.
The main reason that I have a Mikrotik at home is to do things that I cannot do using the ISP’s Home Gateway, like having a separate, untrusted IoT vlan and a guest vlan.
mDNS Repeater is needed to make some services work across vlans, like printing, casting and etc.
In a business environment, wired printers can often be on their own VLAN, or one separate from Wireless devices. Without mDNS between the networks, the built in discovery tools for printing in a lot of mobile and wireless devices does not work. It prevents printing from some mobile devices to another network. Manual setup of DNS for this is long-winded and does not always work correctly (possibly wide-area bonjour).
There is also streaming to projectors and smart tvs/sticks that rely on the devices being on the same network for discovery, which is not always true in a business environment.
That is what I have seen in my experience.
You understand than mDNS do not do NAT, routing, firewall, etc. but just resolve address?
If you can comunicate between VLANs… the VLANs for this do not have any sense!
Understand?
nonsense is your posts, if you don't see a reason to use it, does not mean that no one can have a reason to need it.
Want a example? I want to all devices not be able to access/scan devices on my main "trusted" vlan, but still my devices on the trusted vlan be able to talk with those IoT, not backwards. Any connection started on trusted side is permitted, not the ones started on the untrusted that are not to the internet.
Ps. if you dont have a reason to post something useful, don't post, people here is just making a reasonable request for a thing that is used by all big players.
removed, useless, see post #41<
of course, I know that. I've FW rules to allow the connections in the way that I do.
Ooooh, you understand now!
@normis, basically some users, like me, want to isolate IoT devices by the L2 domain. but still allowing some connections to start from the trusted side.
some times all this Ch***** crap you will never know…
Ok, you deserve one solution until mDNS is officially supported?
removed, useless, see post #41<
Perfectly valid point.
removed, useless, see post #41<
not in the case of using a Routerboard without a switch chip or with a limited one (like RB4011).
I do not have one 4011 to do some test, sorry 
I think the real problem is Wireless: be always on another switch, not on RTL8367
I don’t have the wireless version. the problem is the RTL8367, it does not support anything besides the same as a $10 switch. anyway, I don’t use it, just the SFP+ port.